On Sun, Aug 30, 2009 at 11:22:39PM +0200, Martin Costabel wrote: > Jack Howarth wrote: > > Considering that Apple's X11 developers are recommending that > > we tell user to nuke their installations and rebuild everything > > from scratch under Snow Leopard as well as never install .la > > files, why don't we take this opportunity to do just that. It may > > cause some minor breakage in fink unstable (which should be > > easily fixable), but we could modify fink to automatically purge > > any *.la files from the packaged files in the debs created. Sure > > we will need to correct some info file to remove the *.la from > > the file list but that will be trivial. We really should embrace > > this opportunity to purge out *.la files from 10.6 and later > > releases.
See below for my thoughts on that proposal. > Is anyone aware of a large-scale test of what happens if we indeed let > libtool build all those *.la files and then simply remove them, despite > each one of them screaming > > # Please DO NOT delete this file! > # It is necessary for linking the library. > > ? Are there situations where they are really useful or perhaps even needed? I think (please chime in here pogma!) they're used by libltdl when it opens libs at runtime. I assume that falls back to opening the lib, but the .la contains the install_name and other synonymous files, so it might be more reliable. I don't know if libltdl uses the dependency info to assist in opening the lib for loaders or loadees that are not fully linked against all dependent libs to resolve symbols. I don't know how libltdl (if no .la present) figures out whether to try a .dylib or a .so. They're used when libtool is used to link against the lib to propagate linking against indirect/dependent libs. I think this is a poor thing to be doing, since it introduces lots of un-necessary linking, which results in lots of extraneous dependency propagation. Some packages now blank the dependency lines in the .la to avoid that mess. Not propagating these subdep links (either blanking dep lines in .la or nuking .la altogether) makes it harder to trace builddepends of packages that use pkgconfig to propagate dependent -I flags. It's probably worth the extra effort to do that tracing correctly instead of side-effect of otherwise-useless linking. They're useful when static-linking an executable or when some intermediate-level lib is available static-only. The .la should propagate the subdependencies of directly linked libs. IMO, static-linking is rarely used by users and many of our libs don't provide .a anyway, so this is not a good reason alone to keep things. > BTW, just for laughs: Those *.la-phobic Apple developers didn't quite > manage to get rid of them: They nuked the standard ones that really hurt > many previously-built dev packages, like libexpat.la, libiconv.la, > libxml2.la, but they didn't look in all subdirectories of /usr/lib. The > result is that the number of *.la files below /usr/lib increased from 75 > (10.5) to 124 (10.6). Debian is moving towards scrapping them in two steps. In the next major release cycle, they're keeping .la but blanking their dependency lines. In the subsequent release cycle, they're eliminating the .la entirely. I don't think that's any better than just nuking them right away, since we always get in trouble when we assume users keep up-to-date regularly and that they don't use fink as a basis for external things that contain propagated .la references. dan -- Daniel Macks dma...@netspace.org http://www.netspace.org/~dmacks ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
