Stan Sander <[email protected]> posted [email protected], excerpted below, on Sun, 25 Jan 2009 18:19:43 -0700:
> My guess is that not too many people have this use flag enabled so it > hasn't gotten a lot of attention and thus has mostly been forgotten. > Just by way of additional help, here is the line for > /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/libgij.la on my system that I > have edited: > > # Libraries that this one depends upon. > dependency_libs='/usr/lib64/gcc/x86_64-pc-linux-gnu/4.3.2/libgcj.la > -lpthread -lrt -ldl -lz' The following is based on what I've read, backed up by experience on my own system, but I don't claim to be a libtool authority by /any/ stretch. YMMV, UAYOR [1], etc. Note that *.la (aka libtool), files are and have always been an inelegant solution to one problem that unfortunately comes with a whole host of additional problems. In MOST cases, it's actually possible to delete the *.la files entirely. The system in many ways works better without them than with them, as gcc, libtool and ld can usually detect the libraries anyway. The most common exception is "plugins", which on Linux are shared object (*.so) files just like ordinary libraries, only they're linked and loaded differently, such that the application can be used with or without them. Apparently "plugins" (and other similarly loaded libraries) need or often need the *.la files in ordered to function correctly. From what I've read, KDE in particular uses this style of loading relatively frequently, so other than known plugins (as for browsers, or codecs for xine and mplayer), KDE tends to be more likely to break than most stuff if a particular *.la file is missing. Thus, one way to potentially solve such *.la issues is to rename the file to something like *.la.remove, or *.la.remove.yyyymmdd (where yyyymmdd is a date string), thus taking it out of normal usage and out of revdep- rebuild's view. If nothing using that library seems to break upon restarting it, you can then go ahead and delete it. (Alternatively for those who had FEATURES=buildpkg set when they merged that package and thus have the binpkg, simply delete the *.la immediately, as it's easy enough to remerge the binpkg if the *.la file turns out to be needed for something.) Since I figured that out, I've had much less problems with *.la files. If they start giving me problems, I just delete them, knowing I can grab them from the binpkg (or simply remerge it) if I need 'em. Once you know for sure that a particularly troublesome *.la is /not/ needed it can be added to INSTALL_MASK in make.conf, thereby keeping it from being reinstalled when the package is remerged or updated. I wouldn't worry about it in most cases, tho, only in cases like this (again, only once you know that killing the *.la isn't going to break something else due to that corner-case) where it's a repeating problem that you're tired of dealing with. --- [1] (http://www.acronymfinder.com/Use-At-Your-Own-Risk-(UAYOR).html -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
