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