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

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

[Duncan]

"Nadav Horesh" <nadavh@visionsense.com> posted
710F2847B0018641891D9A21602763600B6DEB@ex3.envision.co.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@gentoo.org mailing list

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

[Nadav Horesh]

[-- Attachment #1: Type: text/plain, Size: 10773 bytes --]

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.

   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@lists.gentoo.org
Subject: [gentoo-amd64]  Re: gnome installation problem: unreslved references in the gst libraries
 
"Nadav Horesh" <nadavh@visionsense.com> posted
710F2847B0018641891D9A21602763600B6DEB@ex3.envision.co.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@gentoo.org mailing list



[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 8350 bytes --]

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

[Duncan]

"Nadav Horesh" <nadavh@visionsense.com> posted
710F2847B0018641891D9A21602763600B6DF0@ex3.envision.co.il, excerpted
below, on  Wed, 10 Oct 2007 07:13:16 +0200:

> I set the compilation flags to the recommended (-O2 -march=k -pipe)

Hope the above is a typo.  That should be -march=k8 (you missed the 8).  
I'd simply assume it was a typo and not mention it, but if that turned 
out to be the problem... =8^(

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

Well, it was a shot in the dark anyway...

BTW, something in the above prodded my memory...  You don't still happen 
to have the old gstreamer 0.8 series do you?  Current is 0.10 series, and 
it's possible if you still have some of the old stuff around, that's 
what's causing the incompatibility.

>    Nadav.
> 
> N.B.
> 
> 1. I am a speed freak, thus I use XFCE. I use the gnome package mainly
> for its utilities.

I like speed, but I like control and features better, I think, and since 
I have a dual Opteron, RAID, and an almost embarrassing 8 gigs memory, 
I've obviously thrown hardware at the problem rather than go the 
conservative memory route. =8^P  (I've observed to myself several times 
that the hardware folks should really be pushing Linux, as if folks don't 
spend the money on software, they have that much more to spend on 
hardware... and I've done just that! =8^)

Still, I'd certainly try and may stay xfce if I were running a more 
conventional single disk, single cpu/core, half-gig memory or less 
system.  Of course, I'd be much more likely to be doing it on a binary 
distribution instead of Gentoo in that case, but anyway...

 2. I did use your recommended flags as you mentioned.

=8^)  I figured that was too close to be coincidence.  

The main thing I worry about is that while yes, it's great playing around 
with these nice fancy CFLAG options, I hope that folks don't miss the 
fact that to some extent it is "out there" a bit, and as such, it /will/ 
mean fighting with things every once in awhile to get stuff compiled, 
where a more conservative "-march=k8 -O2 -pipe" will be /almost/ as good, 
and more likely to "just work", with less emerge failures and the like.

I recognize that not all computer users have the luxury of treating 
computing as a hobby, as I do, and that some prefer it "just work", and 
the less hassle to get to that state, the happier they'll be.  (I OTOH 
enjoy a bit of a challenge on occasion, the precise reason I like 
bleeding edge.  If it always "just worked", I'd be about as likely to 
find it interesting as a hobby as I am to find staring at the microwave 
or freezer "interesting"! =8^)

The concern therefore is that folks will grab my options and then wonder 
why they don't always work, as much as it is countering the myth that 
one /cannot/ run such options regularly, and only the ricers and insane 
try.  It's fine to want to experiment and run unusual cflags and test new 
packages, and in fact, /someone/ as to do it, as long as you realize the 
extra investment in time and occasional hassle it's likely to bring with 
it. =8^)

But it looks like you are pretty well aware of the issues already, and 
have made your choice knowing the tradeoffs.

-- 
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@gentoo.org mailing list

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

[Drake Donahue]

----- Original Message ----- 
From: "Nadav Horesh" <nadavh@visionsense.com>
To: <gentoo-amd64@lists.gentoo.org>
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@lists.gentoo.org
Subject: [gentoo-amd64]  Re: gnome installation problem: unreslved 
references in the gst libraries

"Nadav Horesh" <nadavh@visionsense.com> posted
710F2847B0018641891D9A21602763600B6DEB@ex3.envision.co.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@gentoo.org mailing list



-- 
gentoo-amd64@gentoo.org mailing list

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

[Nadav Horesh]

[-- Attachment #1: Type: text/plain, Size: 4198 bytes --]


O.K, I have a previous installation of gstreamer-0.8.11. I'll try to dismiss it, but it may not be trivial.

B.T.W
  The speed of xfce (at least relative to gnome) come from that that most desktop actions are at your fingertips, so don't have to move your arm that much.


 Nadav.

-----Original Message-----
From: news on behalf of Duncan
Sent: Wed 10-Oct-07 11:27
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64]  Re: gnome installation problem: unreslved references in the gst libraries
 
"Nadav Horesh" <nadavh@visionsense.com> posted
710F2847B0018641891D9A21602763600B6DF0@ex3.envision.co.il, excerpted
below, on  Wed, 10 Oct 2007 07:13:16 +0200:

> I set the compilation flags to the recommended (-O2 -march=k -pipe)

Hope the above is a typo.  That should be -march=k8 (you missed the 8).  
I'd simply assume it was a typo and not mention it, but if that turned 
out to be the problem... =8^(

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

Well, it was a shot in the dark anyway...

BTW, something in the above prodded my memory...  You don't still happen 
to have the old gstreamer 0.8 series do you?  Current is 0.10 series, and 
it's possible if you still have some of the old stuff around, that's 
what's causing the incompatibility.

>    Nadav.
> 
> N.B.
> 
> 1. I am a speed freak, thus I use XFCE. I use the gnome package mainly
> for its utilities.

I like speed, but I like control and features better, I think, and since 
I have a dual Opteron, RAID, and an almost embarrassing 8 gigs memory, 
I've obviously thrown hardware at the problem rather than go the 
conservative memory route. =8^P  (I've observed to myself several times 
that the hardware folks should really be pushing Linux, as if folks don't 
spend the money on software, they have that much more to spend on 
hardware... and I've done just that! =8^)

Still, I'd certainly try and may stay xfce if I were running a more 
conventional single disk, single cpu/core, half-gig memory or less 
system.  Of course, I'd be much more likely to be doing it on a binary 
distribution instead of Gentoo in that case, but anyway...

 2. I did use your recommended flags as you mentioned.

=8^)  I figured that was too close to be coincidence.  

The main thing I worry about is that while yes, it's great playing around 
with these nice fancy CFLAG options, I hope that folks don't miss the 
fact that to some extent it is "out there" a bit, and as such, it /will/ 
mean fighting with things every once in awhile to get stuff compiled, 
where a more conservative "-march=k8 -O2 -pipe" will be /almost/ as good, 
and more likely to "just work", with less emerge failures and the like.

I recognize that not all computer users have the luxury of treating 
computing as a hobby, as I do, and that some prefer it "just work", and 
the less hassle to get to that state, the happier they'll be.  (I OTOH 
enjoy a bit of a challenge on occasion, the precise reason I like 
bleeding edge.  If it always "just worked", I'd be about as likely to 
find it interesting as a hobby as I am to find staring at the microwave 
or freezer "interesting"! =8^)

The concern therefore is that folks will grab my options and then wonder 
why they don't always work, as much as it is countering the myth that 
one /cannot/ run such options regularly, and only the ricers and insane 
try.  It's fine to want to experiment and run unusual cflags and test new 
packages, and in fact, /someone/ as to do it, as long as you realize the 
extra investment in time and occasional hassle it's likely to bring with 
it. =8^)

But it looks like you are pretty well aware of the issues already, and 
have made your choice knowing the tradeoffs.

-- 
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@gentoo.org mailing list



[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 5134 bytes --]