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