Bug 139445 - KDE requires *.la files to load dynamic modules/libs while in most cases *.la files are simply not needed
Summary: KDE requires *.la files to load dynamic modules/libs while in most cases *.la...
Status: RESOLVED INTENTIONAL
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Stephan Kulow
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-31 15:51 UTC by Arkadiusz Miskiewicz
Modified: 2007-01-12 17:27 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
modified arts patch, doesn't require .mcopclass modifications (2.49 KB, patch)
2007-01-12 17:27 UTC, Rex Dieter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arkadiusz Miskiewicz 2006-12-31 15:51:21 UTC
Version:            (using KDE KDE 3.5.5)
Installed from:    Compiled From Sources
OS:                Linux

kdelibs libraries loader explictly wants to load libraries by *.la files even if these files do not exists.

libltdl used in kde can deal with raw *.so libraries, too. 

My whishlist is to add fallback to loading *.so.X.Y.Z if *.la loading fails.

Here is the patch that just switch from la loading to direct so loading:
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/kdelibs-lib_loader.patch?rev=1.1

In PLD we have smart rpm that finds dependencies based on *.la files, example

libkdeprint.la:

# Libraries that this one depends upon.
dependency_libs=' -L/usr/lib /usr/lib/libkparts.la /usr/lib/libkio.la /usr/lib/libkdeui.la /usr/lib/libkdesu.la /usr/lib/libkwalletclient.la /usr/lib/libkdecore.la
/usr/lib/libstdc++.la /usr/lib/libDCOP.la -lresolv -lutil /usr/lib/libart_lgpl_2.la /usr/lib/libidn.la /usr/lib/libkdefx.la /usr/lib/libqt-mt.la -lXmu -lXrender -lX
randr -lXcursor -lXinerama -lXft -lfreetype -lfontconfig -lXext -lX11 -lSM -lICE -lGL /usr/lib/libXmu.la /usr/lib/libXt.la /usr/lib/libXrandr.la /usr/lib/libXcursor
.la /usr/lib/libXfixes.la /usr/lib/libXinerama.la /usr/lib/libXft.la /usr/lib/libfontconfig.la /usr/lib/libfreetype.la /usr/lib/libexpat.la -lpng /usr/lib/libXext.l
a /usr/lib/libSM.la /usr/lib/libICE.la /usr/lib/libXrender.la /usr/lib/libX11.la /usr/lib/libxcb-xlib.la /usr/lib/libxcb.la /usr/lib/libXau.la /usr/lib/libXdmcp.la
-ldl /usr/lib/libfam.la -lpthread /usr/lib/libacl.la /usr/lib/libattr.la -lz /usr/lib/libstdc++.la'

so our rpm will put Requires: for each package that provides these la files. That means that pure runtime library kdeprint brings tooons of -devel subpackages just because in KDE *.la files NEED to be in base/core packages even if library loader can live without *.la files.
Comment 1 Stephan Kulow 2007-01-08 13:00:21 UTC
KDE4 has no .la files and KDE3 will stay as it is.
Comment 2 Rex Dieter 2007-01-08 18:27:41 UTC
Arkadiusz, how does the patch work in practice?  I've run into more than a few loadable modules with unresolved symbols, that would likely break if it weren't for the .la files loading the necessary (and even some extraneous) libs.
Comment 3 Arkadiusz Miskiewicz 2007-01-08 22:44:36 UTC
Does deps loading from *.la work at all in libltdl? libtool documentation says that's not implemented.

Anyway module which isn't linked to all required libraries is simply broken and should be properly linked (exactly the same case as with standard shared libraries).

There is better change:
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/kdelibs-lib_loader.patch?rev=1.2
that loads so.x.y.z libraries first but also have fallback to *.la loading. Unfortunately implementation uses boost crap instead of pure qt.
Comment 5 Rex Dieter 2007-01-11 22:05:44 UTC
Bummer, artsd segfaults for me using this latter patch.
Comment 6 Arkadiusz Miskiewicz 2007-01-11 22:19:33 UTC
Provide more details, backtrace etc...
Comment 7 Paweł Sikora 2007-01-11 22:23:47 UTC
patched kdelibs and arts were tested with kdemultimedia
and akode (built with --witout-libltdl) and work fine.
Comment 8 Rex Dieter 2007-01-11 22:41:57 UTC
on RHEL4:

Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1209050912 (LWP 29362)]
[KCrash handler]
0x003f57a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#0  0x003f57a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00652393 in __waitpid_nocancel () from /lib/tls/libpthread.so.0
#2  0x08055a5a in Arts::CrashHandler::defaultCrashHandler (sig=11)
    at crashhandler.cc:220
<blips by too fast to catch>
#4  Arts::Loader_base::_create (subClass=@0x0) at core.cc:2775
#5  0x0805e451 in Arts::SoundServerV2_impl::checkNewObjects (this=0x0)
    at ../mcop/reference.h:90
#6  0x0805f010 in SoundServerV2_impl (this=0x81731f0)
    at soundserverv2_impl.cc:53
#7  0x080626d1 in SoundServerV2_impl_Factory::createInstance (this=0x806fb90)
    at soundserverv2_impl.cc:383
#8  0x002e9b06 in Arts::ObjectManager::create (this=0x81586c0, 
    name=@0xbff26840) at objectmanager.cc:59
#9  0x00576f9a in Arts::SoundServerV2_base::_create (subClass=@0x0)
    at soundserver.cc:1683
#10 0x0057cb6a in Arts::SoundServerV2::_Creator ()
    at /usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/ext/new_allocator.h:62
#11 0x08059939 in main (argc=14, argv=0xbff26ab4) at ../mcop/reference.h:124
#12 0x00422de3 in __libc_start_main () from /lib/tls/libc.so.6
#13 0x08053e11 in _start ()
Comment 9 Paweł Sikora 2007-01-11 22:52:22 UTC
#5  0x0805e451 in Arts::SoundServerV2_impl::checkNewObjects (this=0x0) 
                                                            ^^^^^^^^^^^
     at ../mcop/reference.h:90 
#6  0x0805f010 in SoundServerV2_impl (this=0x81731f0) 
                                      ^^^^^^^^^^^^^^

and how this trash is related to the loader patch?
Comment 10 Rex Dieter 2007-01-11 23:08:38 UTC
Dunno, all I know is that it crashes when built with the above backtrace when built with said patch, and doesn't without it.

How about this, when I run artsd by hand, gives something more interesting:
MCOP ObjectManager: Could not load extension libartsmidi.la.
MCOP ObjectManager: can't find implementation for Arts::MidiManager.
loading extension from '/usr/lib/libartsbuilder.la.la' failed: file not found
MCOP ObjectManager: Could not load extension libartsbuilder.la.
MCOP ObjectManager: can't find implementation for Arts::ArtsBuilderLoader.

Looks like the .mcopclass files also need some .la stripping, I'd venture (yup, looking at the pld arts.spec confirms my suspicion).  OK, I'll go try that.
Comment 11 Paweł Sikora 2007-01-11 23:19:15 UTC
yes, arts and kdemultimedia need such fixup.

$ find . -type f -name '*.mcopclass' | xargs sed -i -e 's:\.la::'
Comment 12 Rex Dieter 2007-01-12 14:02:33 UTC
Hmm... I can see how that might be problematic, mixing/matching patched/non-patched instances of arts/kdemultimedia/akode (or another pkg providing .mcopclass files).  I'll see if I can grok the code enough to modify it to "just work", without having to modify .mcopclass files.
Comment 13 Rex Dieter 2007-01-12 17:27:02 UTC
Created attachment 19238 [details]
modified arts patch, doesn't require .mcopclass modifications

Here's my quick-n-dirty attempt at modifying the arts-extension_loader.patch
not not require modification of .mcopclass files, by stripping the .la
extention itself.

In short, in makeLibraryName, replace:
std::string p = dir + "/" + name;
with
boost::regex p_regex;
p_regex.assign("(.+)\\.la$");
std::string p = dir + "/" + boost::regex_replace( name, p_regex, "$1",
boost::match_default);

Make sense?