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
> versions.)
> 
> 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
problems.

> 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
> business.
> 
> 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
-- 
gentoo-amd64@g.o mailing list