libtool/ltmain linking wrong stdc++
Hi All, Searching the list archives, I see that other people have had this problem too, but the solutions in those threads don't really seem to work for me... My problem is that I have 2 compilers installed on my computer: gcc-3.4 in /usr (system compiler), and gcc-3.3 in /opt/gcc-3.3. When compiling /opt/gcc-3.3/bin/gcc-g++-3.3, I get link errors because libstdc++.so is resolved to /usr/lib/libstdc++.so (the system lib), instead of the compilers lib in /opt/gcc-3.3/lib. When I delete the /usr/lib/libstdc++.so symlink, I get the error "Could not find /usr/lib/libstdc++.so" when linking. The libtool command looks like this: /bin/sh ../../../libtool --silent --tag=CXX --mode=link apg++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION-o amarok -L/opt/kde/lib -L/usr/lib/qt/lib -L/usr/X11R6/lib-R /opt/kde/lib -R /opt/kde/lib -R /usr/lib/qt/lib -R /usr/X11R6/lib loader.o splash.o -lqt-mt -lz -lpng -lz -lm -lXext -lX11 -lSM -lICE -lpthread -lkdecore The command passed to g++ is: apg++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -o amarok loader.o splash.o -L/opt/kde/lib -L/usr/lib/qt/lib -L/usr/X11R6/lib -lm /opt/kde/lib/libkdecore.so -L/usr/i486-slackware-linux/bin -L/usr/i486-slackware-linux/lib -L/usr/lib/gcc/i486-slackware-linux/../../../i486-slackware-linux/lib -L/usr/lib/gcc/i486-slackware-linux/../.. /opt/kde/lib/libDCOP.so -lresolv -lutil -L/usr/lib /usr/lib/libart_lgpl_2.so /usr/lib/libidn.so /opt/kde/lib/libkdefx.so /usr/lib/qt/lib/libqt-mt.so -lfontconfig /usr/lib/libmng.so -ljpeg -lGL -lXmu -lXrandr -lXcursor -lXinerama -lXft /usr/X11R6/lib/libfontconfig.so /usr/lib/libfreetype.so /usr/lib/libexpat.so -ldl -lpng -lz -lXext -lX11 -lSM -lICE -lpthread -lXrender /usr/lib/libstdc++.so -Wl,--rpath -Wl,/opt/kde/lib -Wl,--rpath -Wl,/usr/lib/qt/lib -Wl,--rpath -Wl,/usr/X11R6/lib -Wl,--rpath -Wl,/opt/kde/lib -Wl,--rpath -Wl,/usr/lib/qt/lib -Wl,--rpath -Wl,/usr/X11R6/lib compiler_lib_search_path is "-L/opt/gcc-3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3.6 -L/opt/gcc-3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../.." I stuck an echo test in the "for searchdir in $newlib_search_path $lib_search_path $sys_lib_search_path $shlib_search_path; do" loop (line 1836 of ltmain.sh), to see what was being run through it. The libs being resolved are: qt-mt, png, z, Xext, X11, SM, ICE, pthread, kdecore, m, resolv, util, mng, freetype, jpeg, GL, dl, png, z, pthread. Not anything from postdeps (-lstdc++ -lm -lgcc_s -lc -lgcc_s) is being run through. The dirs being searched are: /opt/kde/lib /usr/lib/qt/lib /usr/X11R6/lib /home/taj/amarok-apkg/amarok-1.4.3/amarok/src/loader /opt/kde/lib /usr/lib/qt/lib /usr/X11R6/lib /lib /usr/lib /usr/local/lib I'm not sure where libstdc++.so is being resolved. Any ideas how I can force libstdc++.so to be resolved to the compilers libstdc++? Thanks! Taj ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain linking wrong stdc++
Ralf Wildenhues gmx.de> writes: Hi Ralf, Thanks for the reply! > Please rerun the link command with --debug and without --silent: > /bin/sh ../../../libtool --debug --tag=CXX --mode=link ... >log 2>&1 > gzip -9 log http://wildgardenseed.com/Taj/libtool-log > and attach log.gz. Please also send the output of > /bin/sh ../../../libtool --tag=CXX --config http://wildgardenseed.com/Taj/libtool-config Cheers, Taj ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain linking wrong stdc++
Mike Frysinger gentoo.org> writes: > > On Monday 09 October 2006 11:07, Taj Morton wrote: > > My problem is that I have 2 compilers installed on my computer: gcc-3.4 in > > /usr (system compiler), and gcc-3.3 in /opt/gcc-3.3. > > what you want to do just wont work regardless of the issue you raise below > ... > gcc 3.3 and gcc 3.4 have incompatible ABI's so you cannot mix things built > with the two compilers as you'll just end up with some things using > libstdc++.so.5 while others use libstdc++.so.6 Yes, I know that gcc-3.2/3.3 and gcc 3.4/4.0 have different ABIs. The reason I'm doing this is to build compatible binaries that can be run on systems with gcc-3.3 AND on systems with gcc-3.4 (I'm using autopackage, see www.autopackage.org). > > > I'm not sure where libstdc++.so is being resolved. Any ideas how I can > > force libstdc++.so to be resolved to the compilers libstdc++? > > this is a feature of libtool and will always cause you problems when you try > to mix compilers that use gcc libtool files > > the linker scripts (.la) encode the full path to the actual linker script ... > so when you build a C++ app, the .la file will encode the full path to the > libstdc++.la file from the gcc compiler that was used to build it > -mike The .la file for me libstdc++.so.5 contains no references to /usr/. I have libdir='/opt/gcc-3.3/lib/.' and dependency_libs contains no -L flags for /usr, /usr/local, /lib, etc. Cheers, Taj ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain linking wrong stdc++
Albert Chin mlists.thewrittenword.com> writes: > > On Mon, Oct 09, 2006 at 03:07:45PM +0000, Taj Morton wrote: > > When compiling /opt/gcc-3.3/bin/gcc-g++-3.3, I get link errors > > because libstdc++.so is resolved to /usr/lib/libstdc++.so (the > > system lib), instead of the compilers lib in /opt/gcc-3.3/lib. When > > I delete the /usr/lib/libstdc++.so symlink, I get the error "Could > > not find /usr/lib/libstdc++.so" when linking. > > What if you set LDFLAGS="-L/opt/gcc-3.3/lib"? No go, it still links against /usr/lib/libstdc++.so. Cheers,, Taj ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain linking wrong stdc++
Ralf Wildenhues gmx.de> writes: > > * Taj Morton wrote on Mon, Oct 09, 2006 at 06:38:10PM CEST: > > Ralf Wildenhues gmx.de> writes: > > > > > Please rerun the link command with --debug and without --silent: > > > /bin/sh ../../../libtool --debug --tag=CXX --mode=link ... >log 2>&1 > > > gzip -9 log > > http://wildgardenseed.com/Taj/libtool-log > > Your /opt/kde/lib/libkdecore.la is listing /usr/lib/libstdc++.la > This pulls in /usr/lib/libstdc++.so. Ah! That's it! Thanks! > > Then you can install that library, and use it. Or if you are > all-powerful on this system, and you are dead certain that the > kdecore library was linked against a libstdc++ compatible with > the one in /opt/gcc-.../, then you can try to edit the file > /opt/kde/lib/libkdecore.la to match this. If I were you, I'd > undo this quickly after using it, and anyway you get to keep the > pieces if anything breaks. Actually, kdecore was NOT linked against libstdc++ in /opt/gcc, it was linked against the one in /usr. The only reason I'm doing this is to build binaries that are compatible with systems both g++-3.2/3.3 and g++-3.4/4.0 systems. I'm compiling separate binaries with the different compilers. I'm using Autopackage (http://www.autopackage.org) which has support for this kind of thing. The way it works: 1. Compile first with CXX=gcc-3.2/3.3. 2. Make clean and compile again with CXX=gcc-3.4/4.0. 3. Diff the C++ binaries and make binary deltas against them. 4. When arriving on the target system, patch binaries if needed and install correct files. Steps 3 and 4 work fine, it's 1`and 2 that I'm having problems with. Is there some way I can force libtool first search the compilers path (dirname `g++ -print-file-name=libstdc++.la`?) for $post_deps? I figured out how to make it search for normal libs, but not post_deps. I don't really have a problem with sedding libtool after ./configure or anything... > Generatlly, you should not link against libraries using two different, > incompatible libstdc++ at the same time. Yeah, it's a bad idea. I'm not talking about /running/ libraries that link against both libstdc++, just compiling them. When they are run, they will only have one libstdc++ linked in. Thanks for your help, Taj ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain linking wrong stdc++
Mike Frysinger gentoo.org> writes: > On Monday 09 October 2006 18:30, Taj Morton wrote: > > Ralf Wildenhues gmx.de> writes: > > > Generatlly, you should not link against libraries using two different, > > > incompatible libstdc++ at the same time. > > > > Yeah, it's a bad idea. I'm not talking about /running/ libraries that link > > against both libstdc++, just compiling them. When they are run, they will > > only have one libstdc++ linked in. > > incorrect ... gcc-3.3 has libstdc++.so.5 while gcc-3.4+ has libstdc++.so.6 Hmm? Yes, I know. > that means if you have bleeding of build environments, it is entirely > possible > to have a library linked against both libstdc++.so.5 and libstdc++.so.6 which > is what i said in my previous e-mail Sorry, I think I didn't make myself clear. Here's the deal: Binaries are compiled with both 3.3 AND 3.4. Both are packaged up. Only the binary that links against the target systems libstd++ is installed. So if you have a Linux install that uses libstdc++.so.5, then the binary compiled with gcc-3.3 is installed. If you have a newer machine that uses libstdc++.so.6, then the binary compiled with gcc-3.4 is installed. I'm trying to *not* build libraries that link to both libstdc++s. Cheers, Taj ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain linking wrong stdc++
Ralf Wildenhues gmx.de> writes: > > * Taj Morton wrote on Tue, Oct 10, 2006 at 06:59:31AM CEST: > > Now, while your libfoo may not be explicitly linked against version Y > (i.e., 'objdump -p libfoo' shows only one libstdc++ as NEEDED), any > program using your libfoo and the installed libkdecore will cause both > versions of libstdc++ to be needed (see 'ldd program' output) because > libkdecore will pull in libstdc++.y. And this can cause pain you don't > want to suffer. Yes, that would cause problems. I know that a C++ app must only have /one/ libstdc+ linked into it (or linked because of dependencies, or dependencies of dependencies, etc). On my build machine (moria), I'm building Amarok, the KDE music player. Amarok is written in C++ and links against kdecore. Moria is building 2 binaries, one that is linked against libstdc++.so.5, and one that links against libstdc++.so.6. The Amarok binary that links against libstdc++.so.5 will ONLY be installed on systems where libkdecore links against libstdc++.so.5. That way, `ldd amarok` will only show libstdc++.so.5, correct? Because kdecore and amarok only links against libstdc++.so.5 (given of course, that everything else links against libstdc++.so.5) Cheers, Taj ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain linking wrong stdc++
Taj Morton gmail.com> writes: > Yes, that would cause problems. I know that a C++ app must only have /one/ > libstdc+ linked into it (or linked because of dependencies, or dependencies of > dependencies, etc). On my build machine (moria), I'm building Amarok, the KDE > music player. Amarok is written in C++ and links against kdecore. Moria is > building 2 binaries, one that is linked against libstdc++.so.5, and one that > links against libstdc++.so.6. Let me rephrase this, hopefully in more understandable terms (s/RPM/Autopackage/g to make the story true): I'm compiling 2 different RPMs for users of my software. One for users who have GCC-3.3 based systems. One for users with GCC-3.4 based systems. I have both GCC-3.3 and 3.4 installed (GCC-3.3 in /opt/gcc-3.3, GCC-3.4 is the system gcc and is in /usr). My problem is that when I compile my GCC-3.3 RPM, libtool links against /usr/lib/libstdc++.so, instead of /opt/gcc-3.3/lib/libstdc++.so. Does that make any more sense? Thanks, Taj ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain linking wrong stdc++
Ralf Wildenhues gmx.de> writes: > > * Taj Morton wrote on Wed, Oct 11, 2006 at 12:43:36AM CEST: > > My problem is that when I compile my GCC-3.3 RPM, libtool links > > against /usr/lib/libstdc++.so, instead of /opt/gcc-3.3/lib/libstdc++.so. > > Yes, you already wrote that. And I already told you possible ways out > of your trouble. Did you just ignore them, or did they not work for > you, or what else was the problem with them? > http://lists.gnu.org/archive/html/libtool/2006-10/msg00027.html Hi, Sorry...I guess I forgot to explain why your suggestion didn't work...please accept my apology. Basically, the problem is that I need a solution that is automatic, that doesn't involve hacking .la files, doesn't require root access, etc. This is because autopackage automatically takes care of compiling with both compilers, and so I can't be manually modifying all the .la files. I was hoping for a solution that maybe involved sedding the libtool file, or something like that. If I can't acomplish it that was, I guess I can just modify Autopackage's wrapper around gcc/g++ to link the compilers libstdc++.so. > Please note that trying to create a library linking against libstdc++.X > and also against a libkdecore that was linked against libstdc++.Y (with > the promise to have, at runtime, a binary compatible libkdecore that was > instead linked against libstdc++.X) sounds like walking a tightrope to > me. Yeah, I know, it is. So far, our testing hasn't shown any problems, so I'm hoping for the best... Thanks for your help, Taj ___ http://lists.gnu.org/mailman/listinfo/libtool
