Version: (using KDE KDE 3.3.1) Installed from: RedHat RPMs Compiler: gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) Fedora Core 3 (up-to-date) OS: Linux kdelibs src.rpm reveals that a copy of GNU libltdl is included, but configured and compiled to not support .so file extensions for shared libraries. Output of configure script: checking which extension is used for shared libraries... That doesn't look intentional and should print ".so". The corresponding part of the configure script runs "sed" on some unexpanded string "$libname${shared_ext}" and therefore results in an empty string instead of the ".so" extension for shared libraries. Consecutively, libltdl in kdelibs is built without code that searches for .so files when called with function lt_dlopenext or lt_dlopen. [...] It has been noticed that Imlib2, a library which uses libtool's API for loading plugins at run-time, fails in Digikam 0.7, because of this (see bug 91759). Imlib2 passes an extension-less library name to lt_dlopenext, which then either loads .la or .so files, if found. So, including .la files in the imlib2 package is not necessary. The example image viewer included with imlib2 works, but is not linked to libkdecore. When called from within Digikam, which is a KDE application and linked against libkdecore, Imlib2's plugin loader fails to find its *.so files, because the libltdl included with KDE is not built with support for .so files.
Confirmed.
After looking at the configure check for shared library extension, I think I've come to the conclusion that the check is fundamentally broken, due to Michael's conclusion regarding unexpanded variables, ${shared_ext} in particular.
Created attachment 8296 [details] hack to hard-code shared_ext=.so Hack to hard-code shared_ext=.so (linux only) to workaround flawed configured check. kdelibs built with this patch made digikam work with a .la-file-less imlib2.
product->kdelibs-3.3.1
That hack is unnecessarily blunt - when packaging kdelibs, just set libltdl_cv_shlibext=".so" in configure's environment and voíla, digikam is fixed. You can even go one better and change if (libname.find('.', pos) < 0) libname += ".la"; ... to ".so" in kdelibs/kdecore/klibloader.cpp and omit packaging _any_ libtool archive for any kde app (except for apps which would try to open a hardcoded path+libraryfile.la - not sure if such applications exist, I doubt it). Of course this will not work on platforms without ELF shared objects.
Is this fixed in kde 3.3.2?
No, it's not fixed in 3.3.2
> ... to ".so" in kdelibs/kdecore/klibloader.cpp and omit packaging _any_ > libtool archive for any kde app (except for apps which would try to open a > hardcoded path+libraryfile.la - Unfortunately, I've discoverred there exists quite a few kde apps/libs that depend on libs referenced in .la files that the associated .so files aren't linked against, which leads to library/kpart/module load failures.
Re: comment #8, see also patches provided in bug #139445 (yay)
May as well bite the bullet and accept that this won't get upstreamed into kde3 anytime soon, nor is there any new releaeses expected. marking WONTFIX. Fwiw, Fedora's kde3 runtime has been patched around this since June'ish 2007 (and my own unofficial builds long before that).