[gentoo-amd64] Re: A different Openoffice Build problem

[Duncan]

felix@×××××××.com posted 20061028062217.GA10209@×××××××.com, 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?

Answering both of those at once...  Take as an example a particular *.la
file with a gcc dependence I have merged here, /usr/lib64/libkbear.la
(part of the kbear package, kbear is a KDE based graphical FTP tool).

There are several entries in this file, but one we are interested in:

# Libraries that this one depends upon.
dependency_libs='-R/usr/kde/3.5/lib64 -R/usr/qt/3/lib64 -R/usr/lib64
-lstdc++ -L/usr/lib64 -L/usr/qt/3/lib64 -L/usr/kde/3.5/lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -L/usr/x86_64-pc-linux-gnu/bin
-L/usr/x86_64-pc-linux-gnu/lib /usr/kde/3.5/lib64/libkparts.la
-L/usr/X11R6/lib64 /usr/kde/3.5/lib64/libkio.la
/usr/kde/3.5/lib64/libkdesu.la /usr/kde/3.5/lib64/libkwalletclient.la
/usr/lib64/libfam.la /usr/kde/3.5/lib64/libkdeui.la
/usr/kde/3.5/lib64/libkdecore.la /usr/kde/3.5/lib64/libDCOP.la -lresolv
-lutil /usr/lib64/libart_lgpl_2.la /usr/lib64/libidn.la
/usr/kde/3.5/lib64/libkdefx.la /usr/qt/3/lib64/libqt-mt.la -lmng -ljpeg
-lXi -lXrender -lXrandr -lXcursor -lXinerama -lXft -lfreetype -lfontconfig
-lXext -lX11 -lSM -lICE /usr/lib64/libmng.la /usr/lib64/liblcms.la
/usr/lib64/libjpeg.la /usr/lib64/libXi.la /usr/lib64/libXrandr.la
/usr/lib64/libXcursor.la /usr/lib64/libXfixes.la /usr/lib64/libXinerama.la
/usr/lib64/libXft.la /usr/lib64/libfontconfig.la /usr/lib64/libfreetype.la
/usr/lib64/libexpat.la -lpng -lz /usr/lib64/libXext.la /usr/lib64/libSM.la
/usr/lib64/libICE.la -lpthread /usr/lib64/libXrender.la
/usr/lib64/libX11.la /usr/lib64/libXau.la /usr/lib64/libXdmcp.la -ldl
-lstdc++ -lc -lgcc_s'

As you can see, gcc/x86_64-pc-linux-gnu/4.1.1 is listed several times in
the file.  It doesn't list 3.4.6 at all, but that's because kbear was
compiled against 4.1.1.  If it had been compiled against 3.4.6, it would
list it, and perhaps not 4.1.1.  What the fix_libtool_files.sh script does
is simply check if the version of gcc you gave it on the command line
matches anything in that list.  If it does, it says "fixing" and adds the
equivalent entry for the current gcc, if it's not already there.

Thus, after the first round of fixes, both paths should be already there,
but additional rounds will still say "fixing" as all it has done at that
point is found an entry that matched what you fed it on the command line
-- it doesn't yet know whether it actually has to add the new version or
if it has already been added.

I think the [v] thing is a fairly new addition to the script.  I'm not
sure (I could go look but I don't want to parse thru all that scripting
to verify), but I'd guess the v's indicate an actual fix. Thus, you can see
some of those had two places to fix the first time thru, others had one,
some had none (they already had both the old and new paths).  On the
second and subsequent runs, they all had the fixes already, so no v's,
even tho there were still matches triggering the "fixing" messages.

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.

In some cases simply removing (rename for testing first) the *.la files in
question works as well or better, forcing the linker to work a bit harder
to find what the *.la file was supposed to be a shortcut to finding, only
the shortcut unfortunately turns into a "longcut" at times!  In theory,
the deletion /should/ work, but we all know theory doesn't always match
reality, thus it's best to try a rename first, just to be safe.

BTW, I know perhaps more about this than most as I ran the
masked-for-testing gcc 4.0 and early 4.1 series, including weekly gcc
alphas (now the gcc-4.2 alphas, but I'm no longer running them) for
awhile.  When your gcc version is changing weekly, you run
fix_libtool_files a LOT!  <g>  Back then at least, the script would
occasionally miss something, and I'd have to go in and add the correct
location by hand, or try renaming/deleting the *.la file entirely.

...

Anyway, you said running the script didn't help, and then tried renaming
the old gcc dirs, and found it breaking earlier.  I could have predicted
that wouldn't work, as if it's not finding 4.1.1, just renaming the old
ones isn't likely to help.  However, you are on the right track for what
I'd suggest next.  You just didn't take it as far as you needed to to get
it to work.

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

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list