1 |
Dang, I should have known you'd answer so much :-) |
2 |
|
3 |
On Sat, Oct 28, 2006 at 08:24:45PM +0000, Duncan wrote: |
4 |
> felix@×××××××.com posted 20061028062217.GA10209@×××××××.com, excerpted |
5 |
> below, on Fri, 27 Oct 2006 23:22:17 -0700: |
6 |
> |
7 |
> > The second run [of fix_libtool_files.sh] drops the v's inside the [], |
8 |
> > and the first four FIXING lines with .../32/... disappear. A third |
9 |
> > rundupped the second run. Seems suspicious to me that it would repeat |
10 |
> > the FIXING lines. |
11 |
> |
12 |
> > I am not sure what you mean by "ensure they have the path" -- how would |
13 |
> > I determine what path they have? |
14 |
|
15 |
I like the full explanation, but I had meant how do I look inside .la |
16 |
files -- I am not familiar with them and had assumed they were some |
17 |
binary format, ELF or related. I did not realize they are just simple |
18 |
text files :-) |
19 |
|
20 |
> So that's the explanation. What you'd do to "ensure they have the path" |
21 |
> manually would be to open the *.la files the build complains about, and |
22 |
> verify that they point to the correct gcc as well as the old one. |
23 |
|
24 |
The ONLY *.la files it complained about and said it was FIXING are in |
25 |
the /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/ directory, and that |
26 |
doesn't seem like a good place to add 4.1.1 info ... |
27 |
|
28 |
> To do it properly, if you haven't been running FEATURES=buildpkg and thus |
29 |
> already have the packages available, use quickpkg to package up your |
30 |
> gcc-3.4.6 version (and 3.4.2 while you are at it), so you can remerge them |
31 |
> quickly without recompiling, then unmerge them. (Note that in some |
32 |
> circumstances, unmerging the old ones might create issues, but you already |
33 |
> tested most of that with the rename, and your core system continued to |
34 |
> function so apparently at least the core system is fine without the old |
35 |
> versions.) |
36 |
> |
37 |
> Now, run revdep-rebuild -p and see which packages you need to remerge. |
38 |
> One of those is probably what was killing your OOo build. Remerge them as |
39 |
> necessary (either removing the -p or doing it one by one, don't forget the |
40 |
> --oneshot so as not to unnecessarily pollute your world file if you do it |
41 |
> one by one). |
42 |
|
43 |
I'll think about this ... I am going to be away from the machine for a |
44 |
while and this is not a good time to start massive rebuilds or need to |
45 |
fix it up afterwards. OOo is not even a low priority with me. Once |
46 |
in a while I get powerpoint jokes in the mail, but that's about it. |
47 |
Even aside form that, it's a big hairy program, and I was mostly |
48 |
curious about the difference in speed. |
49 |
|
50 |
Nevertheless, apparently I do have some things to fix, and even if I |
51 |
don't care much about OOo itself, it may be a good canary for other |
52 |
problems. |
53 |
|
54 |
> When you are finished with the rebuild, try merging OOo again. If all |
55 |
> goes well, the rebuild will have fixed your problem and you'll be in |
56 |
> business. |
57 |
> |
58 |
> If you have issues after unmerging the old gccs, or run into something |
59 |
> that won't compile with gcc4 but will with gcc3, you have the binary |
60 |
> packages you created before the unmerge, and should be able to remerge |
61 |
> them quickly using emerge's -k switch, along with the =gcc-<ver> syntax to |
62 |
> get the version you want. Having gcc binpkgs around is also quite handy |
63 |
> in case gcc breaks for some reason, since trying to use a broken gcc to |
64 |
> emerge gcc doesn't tend to work so well. |
65 |
|
66 |
Thanks for all the info. |
67 |
|
68 |
-- |
69 |
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. |
70 |
Felix Finch: scarecrow repairman & rocket surgeon / felix@×××××××.com |
71 |
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 |
72 |
I've found a solution to Fermat's Last Theorem but I see I've run out of room o |
73 |
-- |
74 |
gentoo-amd64@g.o mailing list |