1 |
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. |
2 |
It looks that the problem is that when trying to emerge media-related gnome packages they are not linked against the right gstxxx libraries. |
3 |
|
4 |
Nadav. |
5 |
|
6 |
N.B. |
7 |
|
8 |
1. I am a speed freak, thus I use XFCE. I use the gnome package mainly for its utilities. |
9 |
2. I did use your recommended flags as you mentioned. Please continue to educate us. |
10 |
|
11 |
|
12 |
-----Original Message----- |
13 |
From: news on behalf of Duncan |
14 |
Sent: Tue 09-Oct-07 12:05 |
15 |
To: gentoo-amd64@l.g.o |
16 |
Subject: [gentoo-amd64] Re: gnome installation problem: unreslved references in the gst libraries |
17 |
|
18 |
"Nadav Horesh" <nadavh@×××××××××××.com> posted |
19 |
710F2847B0018641891D9A21602763600B6DEB@×××××××××××××××.il, excerpted |
20 |
below, on Tue, 09 Oct 2007 08:55:16 +0200: |
21 |
|
22 |
> I have an ongoing problem with gnome installation started somewhere in |
23 |
> one of the gnome-2.14.x upgrades, and it became worse on every upgrade |
24 |
> till it prevented the upgrade to the recent gnome version (with a |
25 |
> serious side effect of preventing upgrade to python 2.5.1). |
26 |
> |
27 |
> The problem is that in some stage of the build it stops because of an |
28 |
> unresolved reference to some routine in the gstreamer&friends |
29 |
> libraries. It is not a problem of a specific function/library because: |
30 |
> |
31 |
> 1. At different versions of gnome I got different unresolved link. |
32 |
> 2. At the last upgrade, I added a (gstxxx) library that contained the |
33 |
> missing link, what led to error of another missing link in a gstxxx |
34 |
> library. |
35 |
> |
36 |
> I tried "revdep-rebuild" at several stages but it did not help. My |
37 |
> questions are: |
38 |
> |
39 |
> 1. Is there something wrong in my configuration files that might couse |
40 |
> the problem? |
41 |
> 2. Is there a way to rebuild the whole gnome package from scratch? |
42 |
|
43 |
> CFLAGS="-march=k8 -O2 -pipe -frename-registers -fweb -freorder-blocks |
44 |
> -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload |
45 |
> -fmerge-all-constants -mfpmath=sse -msse3 -m3dnow -ftree-vectorize |
46 |
> -falign-functions=64 -fomit-frame-pointer" |
47 |
|
48 |
> CXXFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks |
49 |
> -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload |
50 |
> -fmerge-all-constants -combine -mfpmath=sse -msse3 -ftree-vectorize" |
51 |
|
52 |
> MAKEOPTS="-j2" |
53 |
|
54 |
> USE=[snip] gstreamer [snip] |
55 |
|
56 |
Revdep-rebuild can help so trying it was a good idea, but doesn't always |
57 |
help if there's something else wrong. |
58 |
|
59 |
FWIW, personally, as an admitted control freak when it comes to the |
60 |
desktop I choose to run, I prefer KDE's exposure of options, and despise |
61 |
GNOME's lack of them, so you won't find GNOME on my system and I'm not |
62 |
familiar with it, so there's little I can help if the problem turns out |
63 |
to be GNOME specific. However, it's quite possible the problem is |
64 |
generic enough that the following general hints and techniques may be of |
65 |
help. |
66 |
|
67 |
CFLAGS/CXXFLAGS: Some (but not all) of those C(XX)FLAGS look pretty |
68 |
close to mine. There's nothing wrong with running a big string like |
69 |
that, as long as you understand it may cause problems with some ebuilds, |
70 |
and are willing to try recompiling with something simpler if you do run |
71 |
into issues. |
72 |
|
73 |
In particular -combine doesn't work well at all with CXXFLAGS, and still |
74 |
occasionally (altho much less frequently) causes issues with CFLAGS as |
75 |
well. As I mentioned, some of your flags look like mine, and you may |
76 |
have taken that flag from a discussion here some months ago. Only |
77 |
however it happened, it appears you have -combine in your CXXFLAGS |
78 |
instead of your CFLAGS. I'd reverse that. |
79 |
|
80 |
The problem I've run into is that while -combine is in theory safe for |
81 |
both CFLAGS and CXXFLAGS, because gcc knows when it can't be used (with |
82 |
exceptions for one thing, and they are pretty common in C++/CXX code, |
83 |
thus it's generally not worth even trying there), when gcc removes it, it |
84 |
spits a warning about it. Some of the configure scripts are setup to |
85 |
interpret any warning as an error, and thus decide that whatever they |
86 |
were testing for with that test-compile doesn't work on the system in |
87 |
question. At least in some cases, that causes them to turn OFF something |
88 |
that turns out to be needed later on, thus causing the problem to show up |
89 |
NOT by stopping the configure, but later in the process, during the |
90 |
compile or linking steps. |
91 |
|
92 |
So... try removing -combine from your CXXFLAGS (where as I said gcc |
93 |
normally turns it off anyway), and if you want to continue to use it (I |
94 |
use it), put it in CFLAGS instead. |
95 |
|
96 |
However, the bigger picture message is that sometimes, you may need to |
97 |
try compiling without some of the stuff in your C(XX)FLAGS. You can try |
98 |
one of two things. If you just want to get it to work, or want to see if |
99 |
it's ANYTHING in the C(XX)FLAGS, try setting something really simple, |
100 |
like "-march=k8 -O2 -pipe". If that works, you can try adding a few |
101 |
flags at a time back in and recompiling, until you figure out what's |
102 |
breaking things. Alternatively, if you have some idea what's breaking |
103 |
it, you can try just removing that. If you are wrong and it's the C(XX) |
104 |
FLAGS but a different one, you won't as quickly pin it down the ANY of |
105 |
the C(XX)FLAGS, but if you are right, you'll have eliminated the problem C |
106 |
(XX)FLAG without eliminating any other optimization, and without having |
107 |
to either settle for the generic settings or go thru several tries to get |
108 |
it. So basically, it depends on how sure you are that you know which |
109 |
CFLAG is the issue, before you try again. If you are quite sure, just |
110 |
removing it should be the most efficient way to success. If you aren't |
111 |
even really sure it's the CFLAGS, and are just trying things, you may |
112 |
want to just try the simple thing first, to quickly find out whether it's |
113 |
a CFLAG problem at all. |
114 |
|
115 |
FWIW, -ftree-vectorize is another possible problem CFLAG. The others |
116 |
only seem to cause problems rarely, tho I do remove them when I'm trying |
117 |
for the "simple" CFLAGS option, just to see if the problem is my CFLAGS |
118 |
or not. |
119 |
|
120 |
I also note with interest that you have CXXFLAGS set to -Os, while CFLAGS |
121 |
is set to -O2, plus that specific -falign-functions=64. I just find it |
122 |
strange that someone would have them set differently, is all, tho I /can/ |
123 |
see why someone might choose to do so, given that CXX programs are |
124 |
sometimes bigger programs, and I don't believe it's common to set any of |
125 |
the -falign-X flags, at least in global/system scope context (tho for |
126 |
individual packages may be useful). |
127 |
|
128 |
One more thing with C(XX)FLAGS. Not that this will fix your current |
129 |
problem, but it's useful info... on amd64, the frame pointer isn't needed |
130 |
for debugging, so gcc automatically turns it off at -O1 (-O) and above. |
131 |
The gcc manpage does mention this under the notes for -O1, but says it |
132 |
only applies to some archs, and doesn't say which ones. Apparently, |
133 |
amd64/x86_64 is one such arch where it can and does turn it off, while |
134 |
x86 (32-bit) is not. Thus, the flag makes sense for x86 but not as much |
135 |
for amd64, and that one's pretty much just cluttering up your C(XX)FLAGS |
136 |
lines. I know I had it in my flags too, until someone pointed this out |
137 |
to me, and I ultimately removed it. |
138 |
|
139 |
The same applies to -funit-at-a-time, tho the status here is newer. Unit- |
140 |
at-a-time was introduced with gcc-3.3 IIRC, where it was most definitely |
141 |
NOT default except for -Os, as it still caused a lot of problems. That |
142 |
in fact was the reason -Os was recommended against back at that time -- |
143 |
the unit-at-a-time it enabled just didn't work with a lot of apps back |
144 |
then. Since then, however, the flag has gradually been promoted, until |
145 |
now (gcc 4.2), it's the default with -O1 (IIRC it was the -O2 default |
146 |
with 4.1, and maybe with 4.0). At present, there's still a way to |
147 |
disable it, but the manpage specifically warns that the disabling flag is |
148 |
likely to disappear after a time, so don't use it unless absolutely |
149 |
necessary, and then, plan on fixing the problem before too many more gcc |
150 |
upgrades. So therefore... unless you routinely compile stuff with gcc |
151 |
3.x still, and want -funit-at-a-time for that, it's probably pretty safe |
152 |
to eliminate that from your C(XX)FLAGS as well. Both your C/CXXFLAGS and |
153 |
mine are long enough as it is; no reason to have them any longer than |
154 |
necessary! =8^) |
155 |
|
156 |
Moving on... MAKEOPTS=-j2. While that's recommended and thus relatively |
157 |
common, occasionally individual packages will have problems with it. I |
158 |
actually run -j (no number, thus unlimited jobs) by default, so I |
159 |
probably see issues more often than most, since with that setting it'll |
160 |
try to massively parallelize things if it can, thus being much more apt |
161 |
to actually find any problems that exist. The usual problem here is that |
162 |
an emerge will die when it can't find a file that is created by the same |
163 |
package... only the dependency tree isn't quite complete and under |
164 |
certain circumstances it'll try to create the later file depending on the |
165 |
former, before the former file is itself created! A prime example, fixed |
166 |
quickly once I found and reported the bug, is |
167 |
|
168 |
http://bugs.gentoo.org/show_bug.cgi?id=194720 |
169 |
|
170 |
If you suspect that might be the issue, you can test with MAKEOPTS=-j1 |
171 |
and see. If that fixes it, please file a bug, as I did with the one |
172 |
above. |
173 |
|
174 |
OK, now USE flags. I'm not familiar enough with GNOME to know if |
175 |
gstreamer is a hard dependency or not, but since it's gstreamer causing |
176 |
the problem, if gstreamer isn't a hard dependency, USE=-gstreamer might |
177 |
be enough to avoid the problem. |
178 |
|
179 |
Talking about USE flags... You mention running revdep-rebuild but if you |
180 |
mentioned the -N parameter to emerge, I missed it. -N (--newuse) causes |
181 |
portage to remerge anything where your (or the package's) USE flags have |
182 |
changed since you last merged it. Any time you are having issues such as |
183 |
this, it's a good idea to try running that. As with the -D (--deep) |
184 |
parameter, I prefer to use it routinely, every time I --update world. So |
185 |
I have a little emerge -NuD world script that I run, and don't have to |
186 |
worry about it. Be warned, however; if you've not run an emerge -N world |
187 |
in awhile, you may have quite a list of packages to remerge the first |
188 |
time you try it. |
189 |
|
190 |
Perhaps that'll help with the current problem, perhaps not, but at least |
191 |
some of it should be useful in any case. =8^) |
192 |
|
193 |
-- |
194 |
Duncan - List replies preferred. No HTML msgs. |
195 |
"Every nonfree program has a lord, a master -- |
196 |
and if you use the program, he is your master." Richard Stallman |
197 |
|
198 |
-- |
199 |
gentoo-amd64@g.o mailing list |