Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-amd64
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-amd64@g.o
From: felix@...
Subject: Re: Re: A different Openoffice Build problem
Date: Fri, 27 Oct 2006 23:22:17 -0700
On Sat, Oct 28, 2006 at 04:33:09AM +0000, Duncan wrote:
> felix@... posted 20061027175022.GA16955@..., excerpted
> below, on  Fri, 27 Oct 2006 10:50:22 -0700:
> 
> >  Checking DLL
> > ../unxlngx6.pro/lib/check_libucbhelper3gcc3.so ...: ERROR:
> > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/libstdc++.so.6: version
> > `CXXABI_1.3.1' not found (required by
> > ../unxlngx6.pro/lib/check_libucbhelper3gcc3.so)
> 
> Richard Fish is on the right track here... that error points to a typical
> mixup between gcc 3.x and 4.x.
> 
> However, perhaps the solution is a bit simpler...  Have you tried
> running fix_libtool_files.sh with the old gcc version (3.4.6 in this case,

Ran this, oo failed the same way.  Out of curiousity, I ran
fix_libtool again, and the output differs slightly the second time.

First run:

 * Scanning libtool files for hardcoded gcc library paths...
 *   [1/27] Scanning /lib ...
 *   [2/27] Scanning /usr/lib ...
 *   [3/27] Scanning //usr/lib32/opengl/xorg-x11/lib ...
 *   [4/27] Scanning //usr/lib64/opengl/xorg-x11/lib ...
 *   [5/27] Scanning /emul/linux/x86/lib ...
 *   [6/27] Scanning /emul/linux/x86/usr/lib ...
 *   [7/27] Scanning /emul/linux/x86/usr/qt/2/lib ...
 *   [8/27] Scanning /emul/linux/x86/usr/qt/3/lib ...
 *   [9/27] Scanning /lib32 ...
 *   [10/27] Scanning /lib64 ...
 *   [11/27] Scanning /opt/blackdown-jdk-1.4.2.03/jre/lib/amd64 ...
 *   [12/27] Scanning /opt/insight/lib ...
 *   [13/27] Scanning /usr/X11R6/lib/lesstif ...
 *   [14/27] Scanning /usr/games/lib32 ...
 *   [15/27] Scanning /usr/games/lib64 ...
 *   [16/27] Scanning /usr/kde/3.5/lib ...
 *   [17/27] Scanning /usr/kde/3.5/lib32 ...
 *   [18/27] Scanning /usr/kde/3.5/lib64 ...
 *   [19/27] Scanning /usr/lib32 ...
 *   [20/27] Scanning /usr/lib64 ...
 *     FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/32/libffi.la ...[v]
 *     FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/32/libstdc++.la ...[vv]
 *     FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/32/libsupc++.la ...[vv]
 *     FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/32/libg2c.la ...[v]
 *     FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/libffi.la ...[]
 *     FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/libgcj.la ...[v]
 *     FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/libstdc++.la ...[v]
 *     FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/lib-org-w3c-dom.la ...[v]
 *     FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/lib-org-xml-sax.la ...[v]
 *     FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/libsupc++.la ...[v]
 *     FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/lib-gnu-java-awt-peer-gtk.la ...[]
 *     FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/libg2c.la ...[]
 *   [21/27] Scanning /usr/local/lib ...
 *   [22/27] Scanning /usr/local/lib32 ...
 *   [23/27] Scanning /usr/local/lib64 ...
 *   [24/27] Scanning /usr/qt/3/lib ...
 *   [25/27] Scanning /usr/qt/3/lib32 ...
 *   [26/27] Scanning /usr/qt/3/lib64 ...
 *   [27/27] Scanning /usr/x86_64-pc-linux-gnu/lib ...

The second run 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 going to rename the 3.4.2 (!) and 3.4.6 gcc dirs just to see what
happens ...

> usually fixes the problem.  If not, sometimes it's possible to figure out
> which file the problem is in manually -- do a search in /usr/lib64 (and
> other libdirs, but start with that one) for all *.la files containing 3.4.6
> and ensure they have the path to your current gcc (4.1.1) as well as the
> old 3.4.6 version.

I am not sure what you mean by "ensure they have the path" -- how
would I determine what path they have?

-- 
            ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
     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


Replies:
Re: A different Openoffice Build problem
-- Duncan
Re: Re: A different Openoffice Build problem
-- felix
References:
A different Openoffice Build problem
-- felix
Re: A different Openoffice Build problem
-- Duncan
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: A different Openoffice Build problem
Next by thread:
Re: Re: A different Openoffice Build problem
Previous by date:
Re: gcc 4.1.1 access violation
Next by date:
Re: Re: A different Openoffice Build problem


Updated Jun 17, 2009

Summary: Archive of the gentoo-amd64 mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.