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.
KDE4 has no .la files and KDE3 will stay as it is.
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.
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.
arts patch: http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/arts-extension_loader.patch?rev=1.2
Bummer, artsd segfaults for me using this latter patch.
Provide more details, backtrace etc...
patched kdelibs and arts were tested with kdemultimedia and akode (built with --witout-libltdl) and work fine.
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 ()
#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?
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.
yes, arts and kdemultimedia need such fixup. $ find . -type f -name '*.mcopclass' | xargs sed -i -e 's:\.la::'
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.
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?