Re: libtool/ltmain.sh pulling in wrong stdc++
Am Mittwoch, 3. August 2005 19:11 schrieb Graham Leggett:
Kurt Roeckx said:
Are you sure your libtool has been regenerated for the new g++?
I rebuilt libtool v1.5.8 which was previously installed, and when this
made no difference I downloaded and built libtool v1.5.18.
I deleted config.guess, config.sub, libtool and ltmain.sh and recreated
them from scratch using libtoolize -c -f.
The second project's libtool still somehow detects and pulls in the gcc
v3.4.2 libstdc++, while building with g++ v4.0.1.
I am completely baffled - can anyone reveal what method libtool uses to
detect libraries? What steps are followed to create the dependency_libs
variable within the .la file? I am trying to find out where the referencce
to the 3.4.2 directory is called into existance, but am having no luck.
Regards,
Graham
I also have big problems that libtool tries to use /usr/lib/libstdc++
instead of the compiler one, when I compile several projects.
IMO libtool should always ignore libstdc++, but this is another issue.
I solve the problem by patching libtool after configuration. I change
sys_lib_dlsearch_path_spec and sys_lib_search_path_spec such that
${GCCDIR}/lib is the first entry followed by the default values. This
solves the problem most of the time, but I still hate that libtool does not
ignore libstdc++ in such projects.
Christoph Bartoschek
___
http://lists.gnu.org/mailman/listinfo/libtool
g++ is not used by libtool
Hi, I'm trying to compile fam-2.6.10 from ftp://oss.sgi.com/projects/fam/download/stable/fam-2.6.10.tar.gz The problem is that fam is a C++ library and libtool is not capable of C++. In the linking step the following command is issued: /bin/sh ../libtool --mode=link g++ -g -O2 -o libfam.la -rpath /usr/local/lib -export-symbols fam.sym Client.lo fam.lo -lstdc++ libtool translates this to several commands and this one: gcc -shared Client.lo fam.lo /usr/lib/libstdc++.so -Wl,-soname -Wl,libfam.so.0 -Wl,-retain-symbols-file -Wl,fam.sym -o .libs/libfam.so.0.0.0 Why is not g++ called? Why is /usr/lib/libstdc++.so added to the command line? The correct command line would be: g++ -shared Client.lo fam.lo -Wl,-soname -Wl,libfam.so.0 -Wl,-retain-symbols-file -Wl,fam.sym -o .libs/libfam.so.0.0.0 How can I achieve that g++ is called and not gcc? And how to get rid of /usr/lib/libstdc++.so correctly? I've found the line libfam_la_LIBADD = -lstdc++ in Makefile.in. I guess the fam developers added this line, because libtool was not able to use g++ and they could not figure out how to change this situation. When I remove this line. libtool is not called with -lstdc++ which is also correct, but libtool itself still calls gcc. How to resolve this situation? Christoph Bartoschek ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: g++ is not used by libtool
Am Dienstag, 7. Juni 2005 21:31 schrieb Ralf Wildenhues: Hi Christoph, * Christoph Bartoschek wrote on Tue, Jun 07, 2005 at 08:57:26PM CEST: I'm trying to compile fam-2.6.10 from ftp://oss.sgi.com/projects/fam/download/stable/fam-2.6.10.tar.gz The problem is that fam is a C++ library and libtool is not capable of C++. Libtool /is/ capable of C++. Oh, I want to apologise for writing this sentence. Several issues: First, the libtool that ships with the tarball is *ancient* (1.4, four years old). Tell them to update to a recent one. Second, at the time that libtool was current, it was actually deemed safer bet to link with gcc and add libstdc++ manually than link with g++. (Maybe the latter was even impossible, I don't know -- at the time of libtool-1.4 I did not have anything to do with it yet). How can I achieve that g++ is called and not gcc? And how to get rid of /usr/lib/libstdc++.so correctly? Tell the maintainers of that package to use an up to date libtool. Or update it yourself (1.5.18 is recent, you need to re-libtoolize for ltmain.sh and get aclocal to include the corresponding libtool.m4 into aclocal.m4). Is this easy to do? I guess I have to read libtools documentations. I've found the line libfam_la_LIBADD = -lstdc++ in Makefile.in. Delete that line. And while you're at it, replace AM_PROG_LIBTOOL with AC_PROG_LIBTOOL in configure.in. After all of this you should be set. Well, you won't, because the rest of the package is as unmaintained as the build infrastructure (the C++ standard conformance is rather, um, could be better). Are you sure there is not a more recent version of this package? Regards, Ralf There is a more recent version ftp://oss.sgi.com/projects/fam/download/stable/fam-2.7.0.tar.gz. But it also has the same problems, although it is from 2003. I would like to omit this package, but KDE somehow depends on it and their libtool finds /usr/lib/libstdc++.la, if I do not provide my own version. But I have to prevent that any package uses /usr/lib/libstdc++.so. Thanks, Christoph ___ http://lists.gnu.org/mailman/listinfo/libtool
Adding system dependency path
Hi, I try to compile KDE on a very old system and have one problem. Let me first describe the situation: I have a directory ROOT where nearly all neccessary software is installed. First I installed new binutils in ROOT/gcc then a new gcc version in the same directory. Then I installed nearly all libraries KDE depends on in ROOT. I guess I only left libc and libdl out. Now I want that each new application uses the libraries in ROOT/lib and ROOT/gcc/lib. I tried to achieve it with exporting the following variables: export CPPFLAGS=-IROOT/include export LDFLAGS=-LROOT/lib PATH and LD_LIBRARY_PATH are configured such that ROOT/bin and ROOT/lib are searched first. This procedure seems to work for the libraries KDE depends on, but as soon as I start compiling arts the linking of the first application fails because the wrong libstdc++ is used. The linking step looks something like: libtool ... -LROOT/gcc/lib ... -lstdc++ ... the result is g++ ... -LROOT/gcc/lib /usr/lib/libstdc++.so The correct lib would have been ROOT/gcc/lib/libstdc++.so. Now I have several questions: Why does libtool resolve -lstdc++ to /usr/lib/libstdc++.so? As far as I know each g++ knows where its own libstdc++ resides, such that -lstdc++ would be more correct. But because g++ also implies -lstdc++ it should be omitted at all. If it is not possible that libtool omits the -lstdc++, how can I achieve that ROOT/gcc/lib/libstdc++.so is used? Right now I use a dirty hack. After the configuration step I patch the resulting libtool such that sys_lib_search_path_spec begins with ROOT/gcc/lib and ROOT/lib. What is the correct way to force libtool to always first search in ROOT/lib and ROOT/gcc/lib? Greets, Christoph Bartoschek ___ http://lists.gnu.org/mailman/listinfo/libtool
