[gentoo-amd64] Re: gnome installation problem: unreslved references in the gst libraries

[Duncan]

"Nadav Horesh" <nadavh@×××××××××××.com> posted
710F2847B0018641891D9A21602763600B6DEB@×××××××××××××××.il, excerpted
below, on  Tue, 09 Oct 2007 08:55:16 +0200:

> I have an ongoing problem with gnome installation started somewhere in
> one of the gnome-2.14.x upgrades, and it became worse on every upgrade
> till it prevented the upgrade to the recent gnome version (with a
> serious side effect of preventing upgrade to python 2.5.1).
>
>  The problem is that in some stage of the build it stops because of an
>  unresolved reference to some routine in the gstreamer&friends
>  libraries. It is not a problem of a specific function/library because:
>
>  1. At different versions of gnome I got different unresolved link.
>  2. At the last upgrade, I added a (gstxxx) library that contained the
>  missing link, what led to error of another missing link in a gstxxx
>  library.
>
> I tried "revdep-rebuild" at several stages but it did not help. My
> questions are:
>
> 1. Is there something wrong in my configuration files that might couse
> the problem?
> 2. Is there a way to rebuild the whole gnome package from scratch?

> CFLAGS="-march=k8 -O2 -pipe -frename-registers -fweb -freorder-blocks
> -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload
> -fmerge-all-constants -mfpmath=sse -msse3 -m3dnow -ftree-vectorize
> -falign-functions=64 -fomit-frame-pointer"

> CXXFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks
> -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload
> -fmerge-all-constants -combine -mfpmath=sse -msse3 -ftree-vectorize"

> MAKEOPTS="-j2"

> USE=[snip] gstreamer [snip]

Revdep-rebuild can help so trying it was a good idea, but doesn't always 
help if there's something else wrong.

FWIW, personally, as an admitted control freak when it comes to the 
desktop I choose to run, I prefer KDE's exposure of options, and despise 
GNOME's lack of them, so you won't find GNOME on my system and I'm not 
familiar with it, so there's little I can help if the problem turns out 
to be GNOME specific.  However, it's quite possible the problem is 
generic enough that the following general hints and techniques may be of 
help.

CFLAGS/CXXFLAGS:  Some (but not all) of those C(XX)FLAGS look pretty 
close to mine.  There's nothing wrong with running a big string like 
that, as long as you understand it may cause problems with some ebuilds, 
and are willing to try recompiling with something simpler if you do run 
into issues.

In particular -combine doesn't work well at all with CXXFLAGS, and still 
occasionally (altho much less frequently) causes issues with CFLAGS as 
well.  As I mentioned, some of your flags look like mine, and you may 
have taken that flag from a discussion here some months ago.  Only 
however it happened, it appears you have -combine in your CXXFLAGS 
instead of your CFLAGS.  I'd reverse that.

The problem I've run into is that while -combine is in theory safe for 
both CFLAGS and CXXFLAGS, because gcc knows when it can't be used (with 
exceptions for one thing, and they are pretty common in C++/CXX code, 
thus it's generally not worth even trying there), when gcc removes it, it 
spits a warning about it.  Some of the configure scripts are setup to 
interpret any warning as an error, and thus decide that whatever they 
were testing for with that test-compile doesn't work on the system in 
question.  At least in some cases, that causes them to turn OFF something 
that turns out to be needed later on, thus causing the problem to show up 
NOT by stopping the configure, but later in the process, during the 
compile or linking steps.

So... try removing -combine from your CXXFLAGS (where as I said gcc 
normally turns it off anyway), and if you want to continue to use it (I 
use it), put it in CFLAGS instead.

However, the bigger picture message is that sometimes, you may need to 
try compiling without some of the stuff in your C(XX)FLAGS.  You can try 
one of two things.  If you just want to get it to work, or want to see if 
it's ANYTHING in the C(XX)FLAGS, try setting something really simple, 
like "-march=k8 -O2 -pipe".  If that works, you can try adding a few 
flags at a time back in and recompiling, until you figure out what's 
breaking things.  Alternatively, if you have some idea what's breaking 
it, you can try just removing that.  If you are wrong and it's the C(XX)
FLAGS but a different one, you won't as quickly pin it down the ANY of 
the C(XX)FLAGS, but if you are right, you'll have eliminated the problem C
(XX)FLAG without eliminating any other optimization, and without having 
to either settle for the generic settings or go thru several tries to get 
it.  So basically, it depends on how sure you are that you know which 
CFLAG is the issue, before you try again.  If you are quite sure, just 
removing it should be the most efficient way to success.  If you aren't 
even really sure it's the CFLAGS, and are just trying things, you may 
want to just try the simple thing first, to quickly find out whether it's 
a CFLAG problem at all.

FWIW, -ftree-vectorize is another possible problem CFLAG.  The others 
only seem to cause problems rarely, tho I do remove them when I'm trying 
for the "simple" CFLAGS option, just to see if the problem is my CFLAGS 
or not.

I also note with interest that you have CXXFLAGS set to -Os, while CFLAGS 
is set to -O2, plus that specific -falign-functions=64.  I just find it 
strange that someone would have them set differently, is all, tho I /can/ 
see why someone might choose to do so, given that CXX programs are 
sometimes bigger programs, and I don't believe it's common to set any of 
the -falign-X flags, at least in global/system scope context (tho for 
individual packages may be useful).

One more thing with C(XX)FLAGS.  Not that this will fix your current 
problem, but it's useful info... on amd64, the frame pointer isn't needed 
for debugging, so gcc automatically turns it off at -O1 (-O) and above.  
The gcc manpage does mention this under the notes for -O1, but says it 
only applies to some archs, and doesn't say which ones.  Apparently, 
amd64/x86_64 is one such arch where it can and does turn it off, while 
x86 (32-bit) is not.  Thus, the flag makes sense for x86 but not as much 
for amd64, and that one's pretty much just cluttering up your C(XX)FLAGS 
lines.  I know I had it in my flags too, until someone pointed this out 
to me, and I ultimately removed it.

The same applies to -funit-at-a-time, tho the status here is newer.  Unit-
at-a-time was introduced with gcc-3.3 IIRC, where it was most definitely 
NOT default except for -Os, as it still caused a lot of problems.  That 
in fact was the reason -Os was recommended against back at that time -- 
the unit-at-a-time it enabled just didn't work with a lot of apps back 
then.  Since then, however, the flag has gradually been promoted, until 
now (gcc 4.2), it's the default with -O1 (IIRC it was the -O2 default 
with 4.1, and maybe with 4.0).  At present, there's still a way to 
disable it, but the manpage specifically warns that the disabling flag is 
likely to disappear after a time, so don't use it unless absolutely 
necessary, and then, plan on fixing the problem before too many more gcc 
upgrades.  So therefore... unless you routinely compile stuff with gcc 
3.x still, and want -funit-at-a-time for that, it's probably pretty safe 
to eliminate that from your C(XX)FLAGS as well.  Both your C/CXXFLAGS and 
mine are long enough as it is; no reason to have them any longer than 
necessary! =8^)

Moving on...  MAKEOPTS=-j2.  While that's recommended and thus relatively 
common, occasionally individual packages will have problems with it.  I 
actually run -j (no number, thus unlimited jobs) by default, so I 
probably see issues more often than most, since with that setting it'll 
try to massively parallelize things if it can, thus being much more apt 
to actually find any problems that exist.  The usual problem here is that 
an emerge will die when it can't find a file that is created by the same 
package... only the dependency tree isn't quite complete and under 
certain circumstances it'll try to create the later file depending on the 
former, before the former file is itself created!  A prime example, fixed 
quickly once I found and reported the bug, is 

http://bugs.gentoo.org/show_bug.cgi?id=194720

If you suspect that might be the issue, you can test with MAKEOPTS=-j1 
and see.  If that fixes it, please file a bug, as I did with the one 
above.

OK, now USE flags. I'm not familiar enough with GNOME to know if 
gstreamer is a hard dependency or not, but since it's gstreamer causing 
the problem, if gstreamer isn't a hard dependency, USE=-gstreamer might 
be enough to avoid the problem.

Talking about USE flags...  You mention running revdep-rebuild but if you 
mentioned the -N parameter to emerge, I missed it.  -N (--newuse) causes 
portage to remerge anything where your (or the package's) USE flags have 
changed since you last merged it.  Any time you are having issues such as 
this, it's a good idea to try running that.  As with the -D (--deep) 
parameter, I prefer to use it routinely, every time I --update world.  So 
I have a little emerge -NuD world script that I run, and don't have to 
worry about it.  Be warned, however; if you've not run an emerge -N world 
in awhile, you may have quite a list of packages to remerge the first 
time you try it.

Perhaps that'll help with the current problem, perhaps not, but at least 
some of it should be useful in any case. =8^)

-- 
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

-- 
gentoo-amd64@g.o mailing list