[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CPPUNIT 1.9.14 32 bit error from libtool

From: Saurabh . Bhatnagar
Subject: Re: CPPUNIT 1.9.14 32 bit error from libtool
Date: Mon, 25 Apr 2005 16:05:40 +0530

Ralf, Thanks for your quick reply!

I am sorry, I need to clarify. I hope I am clear this time.

System is sparc-solaris-2.8

I have installed GCC 3.4.2 in my local area and referring to it via PATH and LD_LIBRARY_PATH. I have also installed binutils and dejagnu in my local area.

When I build cppunit in my local area I get the error after gmake creates libcppunit.* in module DllPluginTester :

mkdir .libs
g++ -D__sparc__ -mcpu=ultrasparc3 -m32 -ffor-scope -fno-enforce-eh-specs -fno-const-strings -g -O3 -D__sparc__ -mcpu=ultrasparc3 -Os -o DllPlugInTester DllPlugInTester.o CommandLineParser.o  -ldl ../../src/cppunit/.libs/libcppunit.a -lpthread /user/sbhatnag/gccv3.4.2/lib/libstdc++.so -L/user/sbhatnag/gcc-3.4.2/objdir/sparc-sun-solaris2.8/libstdc++-v3/src -L/user/sbhatnag/gcc-3.4.2/objdir/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -L/user/sbhatnag/gcc-3.4.2/objdir/gcc -Wl,-R -Wl,/user/sbhatnag/gccv3.4.2/lib -Wl,-R -Wl,/user/sbhatnag/gccv3.4.2/lib
ld: fatal: recording name conflict: file `/user/sbhatnag/gccv3.4.2/lib/libstdc++.so' and file `/user/sbhatnag/gcc-3.4.2/objdir/sparc-sun-solaris2.8/libstdc++-v3/src/.libs/libstdc++.so' provide identical dependency names: libstdc++.so.6  (possible multiple inclusion of the same file)
ld: fatal: File processing errors. No output written to DllPlugInTester
collect2: ld returned 1 exit status
gmake[2]: *** [DllPlugInTester] Error 1
gmake[2]: Leaving directory `/user/sbhatnag/cppunit/cppunit-1.9.14/src/DllPlugInTester'


Now, see that the options "-L/user/sbhatnag/gcc-3.4.2/objdir/sparc-sun-solaris2.8/libstdc++-v3/src -L/user/sbhatnag/gcc-3.4.2/objdir/sparc-sun-solaris2.8/libstdc++-v3/src/.libs" are not necessary and are mentioned in the ibcppunit.la file and I removed them.

Ran gmake again(can't clean as that will re-cerate the erroneous .la file), and got the above error again.

This time I also removed the reference to libstdc++.la from the libcppunit.la an viola the build was complete.

OLD dependency_libs=' -lpthread /user/sbhatnag/gccv3.4.2/lib/gcc/sparc-sun-solaris2.8/3.4.2/../../../libstdc++.la -L/user/sbhatnag/gcc-3.4.2/objdir/sparc-sun-solaris2.8/libstdc++-v3/src -L/user/sbhatnag/gcc-3.4.2/objdir/sparc-sun-solaris2.8/libstdc++-v3/src/.libs -L/user/sbhatnag/gcc-3.4.2/objdir/gcc'

NEW dependency_libs=' -lpthread -L/user/sbhatnag/gcc-3.4.2/objdir/gcc'

It built the DllPluginTester and Simple exes. but did not do anything for the other examples.

When I do gmake -k check, the check runs over to other targets after failing in chess.cpp to normal exit.

warm regards


Ralf Wildenhues <address@hidden>

04/25/2005 02:52 PM

Re: CPPUNIT 1.9.14 32 bit error from libtool

* address@hidden wrote on Mon, Apr 25, 2005 at 10:56:01AM CEST:
> I found this BUG :
> http://lists.gnu.org/archive/html/libtool/2004-09/msg00048.html while
> building CPPUNIT 1.9.14 32 bit.

Yes, that is a bug.  But the idea outlined in that thread is not
sufficient to fix the bug.  See [1], where I also outline a different
idea which I think might be feasible, but which would be quite a bit of
work (more than I could invest ATM).

> I have deleted the -L refences to libstdc++ and .la from the dependencies
> of libcppunit.a .
> The library is built but fails in"gmake check" giving this error.
> In file included from main.cpp:6:
> ChessTest.h: In member function `void
> ChessTest<GAMECLASS>::testNumberOfPieces()':
> ChessTest.h:19: error: `m_game' undeclared (first use this function)
> Is this happening because of altering the .la file?

I have no idea.  I believe you are providing way to little information
in order to be able to even reproduce the bug.

What system is this on?  What exactly did you do with the installed .la
files?  Was that even a local install at all, where in?
Note that just deleting library dependencies is not the right thing to
do at all, it has to point to the right libraries instead.

How can we (step by step) reproduce your failure?  Which specific change
exposed the failure (if that can be answered easily)?


[1] http://lists.gnu.org/archive/html/bug-libtool/2005-03/msg00153.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]