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

[Drake Donahue]

----- Original Message ----- 
From: "Nadav Horesh" <nadavh@×××××××××××.com>
To: <gentoo-amd64@l.g.o>
Sent: Wednesday, October 10, 2007 1:13 AM
Subject: RE: [gentoo-amd64] Re: gnome installation problem: unreslved 
references in the gst libraries


Thank you for the detailed answer. I set the compilation flags to the 
recommended (-O2 -march=k -pipe) and the make option to J1, re-emerged the 
whole gstream&friends packages. But it did not help.
It looks that the problem is that when trying to emerge media-related gnome 
packages they are not linked against the right gstxxx libraries.

maybe with the conservative flags and a lot of time try
emerge -uNDe gnome
??

   Nadav.

N.B.

1. I am a speed freak, thus I use XFCE. I use the gnome package mainly for 
its utilities.
2. I did use your recommended flags as you mentioned. Please continue to 
educate us.


-----Original Message-----
From: news on behalf of Duncan
Sent: Tue 09-Oct-07 12:05
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64]  Re: gnome installation problem: unreslved 
references in the gst libraries

"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



-- 
gentoo-amd64@g.o mailing list