On 12/3/05, Alan E. Davis <[EMAIL PROTECTED]> wrote: > I'd like to understand how this works. Is there any documentation of all > this?
The full documentation is "info libtool". Although it is targeted for application developers, it might be useful to browse. But I'll try to give a concise explanation here. > What is the function of the xyz.la file? First, let me talk about the problem that libtool is intended to solve. When you write an application for Unix, you will usually use various libraries. For example, if you write a KDE application, you need to use (called "linking") the KDE libraries to integrate with the environment. For example, /usr/kde/3.5/lib/libkparts.so is a basic KDE library. Now, with gcc, you need to specify all libraries that your application will link against, including dependencies. If you miss one, you will have unresolved functions, and the build will fail. But if you look at the output of "ldd /usr/kde/3.5/lib/libkparts.so", you will see that it depends upon more than one dozen other libraries (if you don't have KDE 3.5, it isn't hard to find a library with a similar issue). The problem however is that the list of required libraries can change from one system to the next. Differences in architecture, configurations, and optional dependency features result in an unmanageable list of dependant libraries. This can be partially managed by configure tricks. You will sometimes see configure scripts doing things like "does -lX11 require -lXdmcp...yes" and so on. While possible, this still requires a great deal of effort on the part of the developer to account for all of the different possibilities, and the level of effort increases exponentially with the number of possible dependencies... Contrast that with a libtool enabled build, the developer only has to link against those libraries the application actually uses (like libkparts.so), and libtool will figure out all of the other dependencies and the actual gcc arguments required to successfully link the program. Sticking with my libkparts.so example, looking at my /usr/kde/3.5/lib/libkparts.la, we find the following two lines (along with others): dlname='libkparts.so.2' dependency_libs=' -R/usr/kde/3.5/lib -R/usr/qt/3/lib -R/usr/X11R6/lib /usr/kde/3.5/lib/libkio.la -L/usr/kde/3.5/lib -L/usr/qt/3/lib -L/usr/X11R6/lib -L/usr/i686-pc-linux-gnu/bin -L/usr/i686-pc-linux-gnu/lib -L/usr/lib /usr/kde/3.5/lib/libkdeui.la /usr/kde/3.5/lib/libkdesu.la /usr/kde/3.5/lib/libkwalletclient.la /usr/kde/3.5/lib/libkdecore.la /usr/kde/3.5/lib/libDCOP.la -lresolv -lutil /usr/lib/libart_lgpl_2.la /usr/lib/libidn.la /usr/kde/3.5/lib/libkdefx.la /usr/qt/3/lib/libqt-mt.la -lmng -ljpeg -lXi -lXrender -lXrandr -lXcursor -lXft -lfreetype -lfontconfig -lXext -lX11 -lSM -lICE /usr/lib/libmng.la /usr/lib/libjpeg.la /usr/lib/libjpeg.la /usr/lib/libXi.la /usr/lib/libXrandr.la /usr/lib/libXext.la /usr/lib/libXcursor.la /usr/lib/libXfixes.la /usr/lib/libXft.la /usr/lib/libfontconfig.la /usr/lib/libXrender.la /usr/lib/libfreetype.la /usr/lib/libfontconfig.la /usr/lib/libfreetype.la /usr/lib/libexpat.la -lpng /usr/lib/libXext.la /usr/lib/libX11.la /usr/lib/libSM.la /usr/lib/libICE.la /usr/lib/libICE.la -lpthread /usr/lib/libXrender.la /usr/lib/libX11.la /usr/lib/libXau.la /usr/lib/libXdmcp.la -ldl -lz /usr/lib/libfam.la -lrpcsvc /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.la' The dlname= parameter says that an application that links against libkparts will actually link against "libkparts.so.2" (you can see this in ldd <program> output). The second parameter is more interesting...it lists gcc flags (the -R and -L entries), required dependant libraries (the -l options, mng, jpeg, Xi, Xrender, etc), and dependant libtool archives (libmng.la, libjpeg.la, libXi.la, ...). Those dependant archives are examined in-turn to locate dlname= and dependancy_lib= settings, and eventually a very long gcc command line is built to accomplish the link. > Are these changes likely to happen in the future as I do emerge -uDv world > from time to time? Yes, as you update gcc versions, switch your system compiler to them (with gcc-config), and prune old versions of gcc. However, upgrades of gcc have to be carefully managed in any case, because if you remove the old version of gcc to early, you can break python, and thus portage, and then you are really screwed. See a recent thread about gcc-3.4 being stabilized for a link to the upgrade procedure. In another posting, you have some .la files that reference .../3.3.6/libstdc++.la. One of those was /usr/lib/libdb_cxx-4.2.la. So if you build something that wants to link against libdb_cxx-4.2, it will link against the stdc++ included with gcc 3.3.6, instead of the 3.4.4 version. But if you were to prune the old version of gcc, this libtool reference would be broken, and the build would fail. You can resolve this with "fix_libtool_files.sh 3.3.6". Finally, all of this applies only for building programs...runtime linking and library resolution is handled through an (almost) completely separate mechanism using /lib/ld-linux.so, /etc/ld.so.cache, and /etc/ld.so.conf. -Richard -- gentoo-user@gentoo.org mailing list
