| 1 |
On Sat, Oct 28, 2006 at 04:33:09AM +0000, Duncan wrote: |
| 2 |
> felix@×××××××.com posted 20061027175022.GA16955@×××××××.com, excerpted |
| 3 |
> below, on Fri, 27 Oct 2006 10:50:22 -0700: |
| 4 |
> |
| 5 |
> > Checking DLL |
| 6 |
> > ../unxlngx6.pro/lib/check_libucbhelper3gcc3.so ...: ERROR: |
| 7 |
> > /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/libstdc++.so.6: version |
| 8 |
> > `CXXABI_1.3.1' not found (required by |
| 9 |
> > ../unxlngx6.pro/lib/check_libucbhelper3gcc3.so) |
| 10 |
> |
| 11 |
> Richard Fish is on the right track here... that error points to a typical |
| 12 |
> mixup between gcc 3.x and 4.x. |
| 13 |
> |
| 14 |
> However, perhaps the solution is a bit simpler... Have you tried |
| 15 |
> running fix_libtool_files.sh with the old gcc version (3.4.6 in this case, |
| 16 |
|
| 17 |
Ran this, oo failed the same way. Out of curiousity, I ran |
| 18 |
fix_libtool again, and the output differs slightly the second time. |
| 19 |
|
| 20 |
First run: |
| 21 |
|
| 22 |
* Scanning libtool files for hardcoded gcc library paths... |
| 23 |
* [1/27] Scanning /lib ... |
| 24 |
* [2/27] Scanning /usr/lib ... |
| 25 |
* [3/27] Scanning //usr/lib32/opengl/xorg-x11/lib ... |
| 26 |
* [4/27] Scanning //usr/lib64/opengl/xorg-x11/lib ... |
| 27 |
* [5/27] Scanning /emul/linux/x86/lib ... |
| 28 |
* [6/27] Scanning /emul/linux/x86/usr/lib ... |
| 29 |
* [7/27] Scanning /emul/linux/x86/usr/qt/2/lib ... |
| 30 |
* [8/27] Scanning /emul/linux/x86/usr/qt/3/lib ... |
| 31 |
* [9/27] Scanning /lib32 ... |
| 32 |
* [10/27] Scanning /lib64 ... |
| 33 |
* [11/27] Scanning /opt/blackdown-jdk-1.4.2.03/jre/lib/amd64 ... |
| 34 |
* [12/27] Scanning /opt/insight/lib ... |
| 35 |
* [13/27] Scanning /usr/X11R6/lib/lesstif ... |
| 36 |
* [14/27] Scanning /usr/games/lib32 ... |
| 37 |
* [15/27] Scanning /usr/games/lib64 ... |
| 38 |
* [16/27] Scanning /usr/kde/3.5/lib ... |
| 39 |
* [17/27] Scanning /usr/kde/3.5/lib32 ... |
| 40 |
* [18/27] Scanning /usr/kde/3.5/lib64 ... |
| 41 |
* [19/27] Scanning /usr/lib32 ... |
| 42 |
* [20/27] Scanning /usr/lib64 ... |
| 43 |
* FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/32/libffi.la ...[v] |
| 44 |
* FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/32/libstdc++.la ...[vv] |
| 45 |
* FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/32/libsupc++.la ...[vv] |
| 46 |
* FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/32/libg2c.la ...[v] |
| 47 |
* FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/libffi.la ...[] |
| 48 |
* FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/libgcj.la ...[v] |
| 49 |
* FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/libstdc++.la ...[v] |
| 50 |
* FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/lib-org-w3c-dom.la ...[v] |
| 51 |
* FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/lib-org-xml-sax.la ...[v] |
| 52 |
* FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/libsupc++.la ...[v] |
| 53 |
* FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/lib-gnu-java-awt-peer-gtk.la ...[] |
| 54 |
* FIXING: /usr/lib64/gcc-lib/x86_64-pc-linux-gnu/3.4.6/libg2c.la ...[] |
| 55 |
* [21/27] Scanning /usr/local/lib ... |
| 56 |
* [22/27] Scanning /usr/local/lib32 ... |
| 57 |
* [23/27] Scanning /usr/local/lib64 ... |
| 58 |
* [24/27] Scanning /usr/qt/3/lib ... |
| 59 |
* [25/27] Scanning /usr/qt/3/lib32 ... |
| 60 |
* [26/27] Scanning /usr/qt/3/lib64 ... |
| 61 |
* [27/27] Scanning /usr/x86_64-pc-linux-gnu/lib ... |
| 62 |
|
| 63 |
The second run drops the v's inside the [], and the first four FIXING |
| 64 |
lines with .../32/... disappear. A third rundupped the second run. |
| 65 |
Seems suspicious to me that it would repeat the FIXING lines. |
| 66 |
|
| 67 |
I am going to rename the 3.4.2 (!) and 3.4.6 gcc dirs just to see what |
| 68 |
happens ... |
| 69 |
|
| 70 |
> usually fixes the problem. If not, sometimes it's possible to figure out |
| 71 |
> which file the problem is in manually -- do a search in /usr/lib64 (and |
| 72 |
> other libdirs, but start with that one) for all *.la files containing 3.4.6 |
| 73 |
> and ensure they have the path to your current gcc (4.1.1) as well as the |
| 74 |
> old 3.4.6 version. |
| 75 |
|
| 76 |
I am not sure what you mean by "ensure they have the path" -- how |
| 77 |
would I determine what path they have? |
| 78 |
|
| 79 |
-- |
| 80 |
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. |
| 81 |
Felix Finch: scarecrow repairman & rocket surgeon / felix@×××××××.com |
| 82 |
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 |
| 83 |
I've found a solution to Fermat's Last Theorem but I see I've run out of room o |
| 84 |
-- |
| 85 |
gentoo-amd64@g.o mailing list |
Archives