Re: Link error for blahS.c when used in multiple GCC environment.
Hello Brendon, * Brendon Costa wrote on Sat, Mar 31, 2007 at 03:53:12AM CEST: > > I am having troubles linking an application in a project that uses > libtool in an environment that has two versions of the GCC compiler. [...] > > 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" Did you do this before running configure? Please post the configure output, and ./libtool --tag=CXX --config Could you also please try adding this to the configure args: ./configure LDFLAGS=-L/home/bcosta/build/install_gcc/lib and see how it fares (i.e., again post the --config output as above, and try to build)? > I am using libtool version: 1.5.18 Well, if you want to try out 1.5.23b, that would be of help, too; however, I don't see anything jumping right at me that we changed that would fix this. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: cygpath usage
* Gary V. Vaughan wrote on Fri, Mar 30, 2007 at 04:30:00PM CEST: > On 29 Mar 2007, at 18:11, Ralf Wildenhues wrote: > >I'd welcome you to do to Libtool what you did to Autoconf > >some years ago. > > Rewrite the guts of it in Perl? Ai-ya! /me runs and hides. No, I meant "generally improve it". Rewriting it in Perl would cause a noticeable execution time regression on modern, non-w32 systems due to the startup overhead, methinks (untested ;-). Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Link error for blahS.c when used in multiple GCC environment.
Ok, I installed libtool 1.5.23b and re-bootstrapped my example project. I have since changed the place where GCC 4.0.1 is installed to avoid confusion with my modified version: GCC 3.3.3 prefix: /usr/ GCC 4.0.1 prefix: /home/bcosta/gcc/install/ set the environment variables: export PATH=/home/bcosta/gcc/install/bin:$PATH export LD_LIBRARY_PATH=/home/bcosta/gcc/install/lib:$LD_LIBRARY_PATH export LDFLAGS=-L/home/bcosta/gcc/install/lib re-ran configure: mkdir -p /home/bcosta/gcc/example cd /home/bcosta/gcc/example ../../dev/edoc/example/configure LDFLAGS=-L/home/bcosta/gcc/install/lib 2>&1 | tee out.txt Giving configure output: checking for doxygen... /usr/pkg/bin/doxygen checking for perl... /usr/pkg/bin/perl checking for dot... /usr/pkg/bin/dot checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for style of include used by make... GNU checking dependency style of g++... gcc3 checking build system type... i386-unknown-netbsdelf3.0 checking host system type... i386-unknown-netbsdelf3.0 checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking dependency style of gcc... gcc3 checking for a sed that does not truncate output... /usr/bin/sed checking for egrep... grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognize dependent libraries... match_pattern /lib[^/]+(\.so|_pic\.a)$ checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 196608 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... NetBSD ld.elf_so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... NetBSD ld.elf_so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... no checking
Re: Link error for blahS.c when used in multiple GCC environment.
* Brendon Costa wrote on Mon, Apr 02, 2007 at 11:42:29PM CEST: > Ok, I installed libtool 1.5.23b and re-bootstrapped my example project. Thanks for all the data. Upon reading, I'm a bit embarassed to see that I could have asked a better question earlier; sorry about that. > /usr/pkg/bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 > -L/home/bcosta/gcc/install/lib -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 Am I right in that you have both a static and a shared library that both link against libstdc++? If yes, why are you doing this (the static lib)? I bet it's the libstdc++.a coming into play... > 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/gcc/example/src/libs/mystatic/.libs/libmystatic.a' > extracting global C symbols from `/home/bcosta/gcc/install/lib/libstdc++.a' ...here, that is causing the problems. I am also very doubtful that such a setup is actually supported by libstdc++. > (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/gcc/install/lib > -L/home/bcosta/gcc/build/i386-unknown-netbsdelf3.0/libstdc++-v3/src > -L/home/bcosta/gcc/build/i386-unknown-netbsdelf3.0/libstdc++-v3/src/.libs > -L/home/bcosta/gcc/build/gcc > ../../../src/plugins/myplugin/.libs/myplugin.a > /home/bcosta/gcc/example/src/libs/mystatic/.libs/libmystatic.a -lm > ../../../src/libs/myshared/.libs/libmyshared.so > ../../../src/libs/mystatic/.libs/libmystatic.a > /home/bcosta/gcc/install/lib/libstdc++.so > ../../../libltdl/.libs/libltdlc.a -Wl,--rpath -Wl,/usr/local/lib > -Wl,--rpath -Wl,/home/bcosta/gcc/install/lib > .libs/library_userS.o(.rodata+0x8414): undefined reference to > `__gnu_internal::palloc_init_mutex' [...] Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link error for blahS.c when used in multiple GCC environment.
Ralf Wildenhues wrote: > * Brendon Costa wrote on Mon, Apr 02, 2007 at 11:42:29PM CEST: >> Ok, I installed libtool 1.5.23b and re-bootstrapped my example project. > > Thanks for all the data. Upon reading, I'm a bit embarassed to see that > I could have asked a better question earlier; sorry about that. > >> /usr/pkg/bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 >> -L/home/bcosta/gcc/install/lib -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 > > Am I right in that you have both a static and a shared library that both > link against libstdc++? If yes, why are you doing this (the static lib)? > > I bet it's the libstdc++.a coming into play... > They are both C++ libraries yes. I do not tell either of them to link with libstdc++ explicitly. The linking lines for the libs are below. There is no mention of libstdc++ in the linking of libmystatic. There is however a reference to libstdc++ while linking libmyshared which is added in by libtool. This should be normal behavior shouldn't it? /usr/pkg/bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -L/home/bcosta/gcc/install/lib -o libmystatic.la -rpath /usr/local/lib -static libmystatic_la-mystatic.lo ar cru .libs/libmystatic.a libmystatic_la-mystatic.o ranlib .libs/libmystatic.a creating libmystatic.la (cd .libs && rm -f libmystatic.la && ln -s ../libmystatic.la libmystatic.la) /usr/pkg/bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -L/home/bcosta/gcc/install/lib -o libmyshared.la -rpath /usr/local/lib libmyshared_la-myshared.lo g++ -shared -nostdlib /usr/lib/crti.o /home/bcosta/gcc/install/lib/gcc/i386-unknown-netbsdelf3.0/4.0.1/crtbeginS.o .libs/libmyshared_la-myshared.o -Wl,--rpath -Wl,/home/bcosta/gcc/install/lib -Wl,--rpath -Wl,/home/bcosta/gcc/install/lib -L/home/bcosta/gcc/install/lib -L/home/bcosta/gcc/install/lib/gcc/i386-unknown-netbsdelf3.0/4.0.1 -L/home/bcosta/gcc/install/lib/gcc/i386-unknown-netbsdelf3.0/4.0.1/../../.. /home/bcosta/gcc/install/lib/libstdc++.so -L/home/bcosta/gcc/build/i386-unknown-netbsdelf3.0/libstdc++-v3/src -L/home/bcosta/gcc/build/i386-unknown-netbsdelf3.0/libstdc++-v3/src/.libs -L/home/bcosta/gcc/build/gcc -lm /home/bcosta/gcc/install/lib/gcc/i386-unknown-netbsdelf3.0/4.0.1/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,libmyshared.so.0 -o .libs/libmyshared.so.0.0 (cd .libs && rm -f libmyshared.so.0 && ln -s libmyshared.so.0.0 libmyshared.so.0) (cd .libs && rm -f libmyshared.so && ln -s libmyshared.so.0.0 libmyshared.so) ar cru .libs/libmyshared.a libmyshared_la-myshared.o ranlib .libs/libmyshared.a creating libmyshared.la (cd .libs && rm -f libmyshared.la && ln -s ../libmyshared.la libmyshared.la) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link error for blahS.c when used in multiple GCC environment.
* Brendon Costa wrote on Tue, Apr 03, 2007 at 12:21:05AM CEST: > > They are both C++ libraries yes. I do not tell either of them to link > with libstdc++ explicitly. The linking lines for the libs are below. Libtool gets the libstdc++ part in, for g++. > There is no mention of libstdc++ in the linking of libmystatic. There is > however a reference to libstdc++ while linking libmyshared which is > added in by libtool. This should be normal behavior shouldn't it? I guess. I meant: why do you have one static and one shared C++ library? What is the need? I guess I need to dig out whether such a setup is supported by GCC. If it is, then it seems we have a Libtool limitation here. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link error for blahS.c when used in multiple GCC environment.
Ralf Wildenhues wrote: > * Brendon Costa wrote on Tue, Apr 03, 2007 at 12:21:05AM CEST: >> They are both C++ libraries yes. I do not tell either of them to link >> with libstdc++ explicitly. The linking lines for the libs are below. > > Libtool gets the libstdc++ part in, for g++. > >> There is no mention of libstdc++ in the linking of libmystatic. There is >> however a reference to libstdc++ while linking libmyshared which is >> added in by libtool. This should be normal behavior shouldn't it? > > I guess. I meant: why do you have one static and one shared C++ > library? What is the need? > I don't need it as such. This is a demonstration project that demonstrates using various linking methods and how that affects the usage of my analysis tool. I assumed creating a static library was possible and that the resulting library could then be used like any other static library on the system. I could always change it to a convenience library which i assume would not suffer from this problem, but it would be good to get to the bottom of this problem. There are probably a lot of other users out there that are doing this that have not come across the problem because they are using a single compiler. I really need to find a resolution to the problem otherwise they will not be able to use my tool unless they also change to convenience libraries which may not be what they want. > I guess I need to dig out whether such a setup is supported by GCC. > If it is, then it seems we have a Libtool limitation here. > I am sorry i don't understand what you mean by whether such a setup is supported by GCC. I will try and compile the project manually without libtool and see if i can get it to work. That might give more of an indication of where the problem might be. Thanks for looking into it. I appreciate the help. Brendon. > Thanks, > Ralf > > ___ http://lists.gnu.org/mailman/listinfo/libtool
