Link error for blahS.c when used in multiple GCC environment.

[Brendon Costa]

Hi,

I am having troubles linking an application in a project that uses
libtool in an environment that has two versions of the GCC compiler.

In normal situations (Single compiler installed) this project builds and
runs fine. However this project is used as a demonstration for a source
analysis program i am writing ( EDoc++:
http://edoc.sourceforge.net/intro.html ) that modifies GCC v4.0.1 and
uses the modified GCC to generate information about the sources while
compiling. So i need it to work in a multi-compiler (though only using
one of the compilers) environment.

Whenever I try to compile using GCC 4.0.1 (Not just my patched one but
also using non-patched GCC 4.0.1) an application in the example project
fails to link due to unresolved symbols used in the library_userS.o file
(library_user is the name of the application).

Basically i think that somewhere libtool is getting confused as to which
of the two libstdc++ libraries it needs to use.

There are two versions of GCC on the system:

Standard GCC distributed with NetBSD:
Version: 3.3.3
Prefix: /usr/
libstdc++: /usr/lib/libstdc++.so
        (libstdc++ version 5.0)

Development GCC that i compile from GCC 4.0.1 sources:
Version: 4.0.1
Prefix: /home/bcosta/build/install_gcc
libstdc++: /home/bcosta/build/install_gcc/lib/libstdc++.so
        (libstdc++ version: 6.5)



When i want to build using the development GCC i do the following:

export PATH="/home/bcosta/build/install_gcc/bin:$PATH"
export LD_LIBRARY_PATH="/home/bcosta/build/install_gcc/lib:$LD_LIBRARY_PATH"


(I DONT KNOW IF I NEED TO EXPORT ANY OTHER ENV VARS TO WORK CORRECTLY
WITH LIBTOOL)

See end of email if you want steps to try and reproduce the problem.

So then i compile the example project. This project has a few libraries,
a few applications and a plugin. The application that fails to link is
called library_user and makes use of a shared lib, static lib and the
plugin.

Libtool generates a file called: library_userS.c and compiles it into an
object file. When linking this with the rest of the objects that make up
the application i see the following:


Making all in library_user
if g++ -DHAVE_CONFIG_H -I.
-I../../../../../dev/edoc/example/src/apps/library_user -I../../..
-I../../..  -I../../../../../dev/edoc/example/src/include
-I../../../../../dev/edoc/example/libltdl
-DBJC_LIBEXECDIR=\"/home/bcosta/build/install_ex/libexec\"
-DBJC_LIBDIR=\"/home/bcosta/build/install_ex/lib\"   -g -O2 -MT
library_user-main.o -MD -MP -MF ".deps/library_user-main.Tpo" -c -o
library_user-main.o `test -f 'main.cpp' || echo
'../../../../../dev/edoc/example/src/apps/library_user/'`main.cpp;  then
mv -f ".deps/library_user-main.Tpo" ".deps/library_user-main.Po"; else
rm -f ".deps/library_user-main.Tpo"; exit 1; fi
/usr/pkg/bin/bash ../../../libtool --tag=CXX --mode=link g++   -g -O2
-o library_user  library_user-main.o
../../../src/libs/myshared/libmyshared.la
../../../src/libs/mystatic/libmystatic.la  ../../../libltdl/libltdlc.la
 -dlopen ../../../src/plugins/myplugin/myplugin.la
mkdir .libs
rm -f .libs/library_user.nm .libs/library_user.nmS .libs/library_user.nmT
creating .libs/library_userS.c
extracting global C symbols from
`../../../src/plugins/myplugin/.libs/myplugin.a'
extracting global C symbols from
`/home/bcosta/build/ex/src/libs/mystatic/.libs/libmystatic.a'
extracting global C symbols from
`/home/bcosta/build/install_gcc/lib/libstdc++.a'
(cd .libs && gcc -c -fno-builtin "library_userS.c")
rm -f .libs/library_userS.c .libs/library_user.nm .libs/library_user.nmS
.libs/library_user.nmT
g++ -g -O2 -o .libs/library_user library_user-main.o
.libs/library_userS.o
-L/home/bcosta/build/gcc/i386-unknown-netbsdelf3.0/libstdc++-v3/src
-L/home/bcosta/build/gcc/i386-unknown-netbsdelf3.0/libstdc++-v3/src/.libs
-L/home/bcosta/build/gcc/gcc
../../../src/plugins/myplugin/.libs/myplugin.a
/home/bcosta/build/ex/src/libs/mystatic/.libs/libmystatic.a -lm
../../../src/libs/myshared/.libs/libmyshared.so
../../../src/libs/mystatic/.libs/libmystatic.a
/home/bcosta/build/install_gcc/lib/libstdc++.so
../../../libltdl/.libs/libltdlc.a -Wl,--rpath
-Wl,/home/bcosta/build/install_ex/lib -Wl,--rpath
-Wl,/home/bcosta/build/install_gcc/lib
.libs/library_userS.o(.rodata+0x8414): undefined reference to
`__gnu_internal::palloc_init_mutex'
.libs/library_userS.o(.rodata+0x841c): undefined reference to
`__gnu_cxx::__pool_alloc_base::_S_end_free'
.libs/library_userS.o(.rodata+0x842c): undefined reference to
`__gnu_cxx::__pool_alloc_base::_S_free_list'
.libs/library_userS.o(.rodata+0x8434): undefined reference to
`__gnu_cxx::__pool_alloc_base::_S_heap_size'
.libs/library_userS.o(.rodata+0x843c): undefined reference to
`__gnu_cxx::__pool_alloc_base::_S_start_free'

... many more errors follow ...


Now those undefined symbols (well i checked the first one) ARE defined
in /home/bcosta/build/install_gcc/lib/libstdc++.so but are NOT defined
in /usr/lib/libstdc++.so

I think that somewhere along the line libtool is using the wrong
libstdc++ or gcc or something. I have not had any problems in the past
compiling other stuff (without libtool) using this method.

Is there something else i should be doing to inform libtool that i want
to use the tool chain defined in: /home/bcosta/build/install_gcc ? Or is
this some sort of obscure bug in libtool?

I am using libtool version: 1.5.18

Thanks,
Brendon.







-- What i used to produce the problem --

If you want to try yourself then you can download the example project
from CVS:

cvs -q -z3 -d:pserver:address@hidden:/cvsroot/edoc login
cvs -q -z3 -d:pserver:address@hidden:/cvsroot/edoc
co example


And GCC source files from:
http://sourceforge.net/project/showfiles.php?group_id=181536

To configure the GCC i use:
./configure --enable-checking --enable-languages=c,c++
--prefix=/home/bcosta/build/install_gcc
--with-local-prefix=/home/bcosta/build/install_gcc

Use GNU make to compile.
gmake && gmake install


This problem will only manifest itself if the version of GCC installed
on the system is a different one to the one being installed in the home
directory: 4.0.1 (It would probably be best with a system installed GCC
3.3.3 as i have, as I found the problem does not occur on my linux box
with GCC 4.1.2 as they probably have very similar libstdc++ implementations)