Bug 93359 - included ltdl library built without support for shared object files
Summary: included ltdl library built without support for shared object files
Status: RESOLVED INTENTIONAL
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 3.5
Platform: Fedora RPMs Linux
: NOR normal with 181 votes (vote)
Target Milestone: ---
Assignee: Stephan Kulow
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-16 13:34 UTC by Michael Schwendt
Modified: 2009-08-14 17:13 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
hack to hard-code shared_ext=.so (637 bytes, patch)
2004-11-16 15:53 UTC, Rex Dieter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Schwendt 2004-11-16 13:34:27 UTC
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.
Comment 1 Rex Dieter 2004-11-16 13:49:24 UTC
Confirmed.
Comment 2 Rex Dieter 2004-11-16 15:50:59 UTC
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.

Comment 3 Rex Dieter 2004-11-16 15:53:40 UTC
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.
Comment 4 Rex Dieter 2004-11-16 17:25:24 UTC
product->kdelibs-3.3.1
Comment 5 Michael Nottebrock 2005-01-20 10:03:49 UTC
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.
Comment 6 tech_support 2005-01-22 23:16:13 UTC
Is this fixed in kde 3.3.2?
Comment 7 Rex Dieter 2005-01-23 05:56:52 UTC
No, it's not fixed in 3.3.2
Comment 8 Rex Dieter 2005-07-20 16:51:41 UTC
> ... 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.
Comment 9 Rex Dieter 2007-01-18 03:39:57 UTC
Re: comment #8, see also patches provided in bug #139445 (yay)
Comment 10 Rex Dieter 2009-08-14 17:13:56 UTC
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).