[gentoo-amd64] Re: gcc with gcj flag revdep loop

[Duncan]

Stan Sander <stsander@×××××.net> posted 497D0FAF.10300@×××××.net,
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