[patch #7055] archive_cmds_need_lc macro check is broken (result check is inverted)
Follow-up Comment #2, patch #7055 (project libtool): attached info: in the archive native-log.txt: link on native mingw ltconfig-native.txt: libtool --config on mingw cross-log.txt and ltconfig-cross.txt same thing while cross compiling on linux please note, while cross compiling the linkers fails to find -lc at all (file #19412) ___ Additional Item Attachment: File name: ltbug.tar.gz Size:5 KB ___ Reply to this item at: http://savannah.gnu.org/patch/?7055 ___ Messaggio inviato con/da Savannah http://savannah.gnu.org/
[patch #7055] archive_cmds_need_lc macro check is broken (result check is inverted)
Follow-up Comment #3, patch #7055 (project libtool): If you want cross compilation, enable it with ./configure --host=i586-mingw32msvc not with ./configure CC=i586-mingw32msvc-gcc That will fix half of your problems. There is still another one in your native build: there, -lc should be ignored as well. It strikes me as odd that the --config output shows $host as empty. It should be a triple matching *-*-mingw*. This causes the failure to ignore -lc. Please find out why your $host is not set correctly: how do you invoke configure? What does the checking host system type... configure check say? Maybe your config.guess and config.sub scripts are not present, or very old? ___ Reply to this item at: http://savannah.gnu.org/patch/?7055 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/
libtool, llvm-gcc, failing C++ exceptions
Using 'llvm-gcc' (GCC frontend to llvm compiler) I find that C++ exceptions do not work (are not caught) in the built programs. When building C++ programs and libraries, libtool tells the compiler to not supply its own runtime or libraries, and then specifies what it believes are the correct runtime and libraries. Over the years I have encountered a number of cases where C++ exceptions don't work, and llvm-gcc (as provided with FreeBSD) is an example. Another case is with 64-bit code on AMD64 Solaris 10 where C++ exceptions don't work in GCC-built code (but they do work with the Sun compiler). An identical problem was reported in 64-bit AMD64 code under FreeBSD 7.2. Unfortunately, this is a complex problem because sometimes the C++ exceptions stop working after a large body of code (e.g. GraphicsMagick + libtiff + ) has been linked into it. It has something to do with process initialization. While it has not been proven yet, I am suspecting that the failing C++ exceptions have something to do with the way that libtool links these modules. Does anyone have ideas about this? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool, llvm-gcc, failing C++ exceptions
Bob Friesenhahn wrote:
While it has not been proven yet, I am suspecting that the failing C++
exceptions have something to do with the way that libtool links these
modules.
Does anyone have ideas about this?
Do all exceptions fail, or just some exceptions?
For example, does something like the following work?
bool handled=false;
try { throw 100; /* or a type local to this compilation unit */ }
catch(int x) { handled=true; }
catch(...)
{
handled=true;
assert(false); // should be handled earlier
}
assert(handled);
Many systems catch exceptions based on the address of a symbol that gets
generated with the class destructor; that's caused all my problems when
passing exceptions between libraries.
- Daniel
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool, llvm-gcc, failing C++ exceptions
On Tue, 5 Jan 2010, dherr...@tentpost.com wrote: Bob Friesenhahn wrote: While it has not been proven yet, I am suspecting that the failing C++ exceptions have something to do with the way that libtool links these modules. Does anyone have ideas about this? Do all exceptions fail, or just some exceptions? For example, does something like the following work? It can not even throw and catch an 'int' in the same scope. I see the same problem (two years now) for an AMD64 build under Solaris 10, but not for an AMD64 build under Linux. The test program I am using is attached. Under Solaris 10, the runtime is nice enough to print this: terminate called after throwing an instance of 'int' Segmentation Fault - core dumped whereas with llvm-gcc under FreeBSD 8.0 I just get: Segmentation fault (core dumped) I have never seen any such problem under SPARC Solaris 10. The test-suite included in my package tests the ability to throw and catch its own exceptions, which are derived in a heirarchical fashion (inheritance) from std::exception. As further clarification, this problem occurs in a static build where the C++ standard library and some other linked-in libraries are shared, but all of my application code (including the throw/catch path being tested) is built as static. In the early days of libtool, the options that GCC would use while linking were teased out of GCC, but then the system linker was used to do the linking. This seemed to cause some problems so now the C++ compiler is used for linking, but libtool tells GCC not to apply any of its normal runtime or libraries, and then libtool passes all of this stuff at link-time. If the compiler is not GCC, then libtool still usually uses the C++ compiler, but it simply tells the C++ compiler to do the link, without trying to intuit what it would do (and the result works). As we have learned, GCC is proven to sometimes lie about the options it would apply given a particular set of options so it seems possible that libtool sometimes applies the wrong options while linking. This is what happens when a small C++ test program is compiled and linked using llvm-c++: depbase=`echo Magick++/tests/exceptions.o | sed 's|[^/]*$|.deps/|;s|\.o$||'`;\ llvm-c++ -DHAVE_CONFIG_H -I. -I/home/bfriesen/src/graphics/GraphicsMagick-head -I./magick -I. -I/home/bfriesen/src/graphics/GraphicsMagick-head -DLT_CONFIG_H='magick/magick_config.h' -DLTDL -I. -I/home/bfriesen/src/graphics/GraphicsMagick-head -Iltdl -I/home/bfriesen/src/graphics/GraphicsMagick-head/ltdl -I/home/bfriesen/src/graphics/GraphicsMagick-head/ltdl/libltdl -I/home/bfriesen/src/graphics/GraphicsMagick-head/Magick++/lib -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/local/include -I/usr/local/include/libxml2 -g -O -march=native -D_THREAD_SAFE -pthread -MT Magick++/tests/exceptions.o -MD -MP -MF $depbase.Tpo -c -o Magick++/tests/exceptions.o /home/bfriesen/src/graphics/GraphicsMagick-head/Magick++/tests/exceptions.cpp \ mv -f $depbase.Tpo $depbase.Po /bin/sh ./libtool --tag=CXX --mode=link llvm-c++ -g -O -march=native -D_THREAD_SAFE -pthread -no-undefined -L/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib -L/usr/local/lib -o Magick++/tests/exceptions Magick++/tests/exceptions.o Magick++/lib/libGraphicsMagick++.la libtool: link: llvm-c++ -g -O -march=native -D_THREAD_SAFE -pthread -o Magick++/tests/exceptions Magick++/tests/exceptions.o -L/usr/local/lib Magick++/lib/.libs/libGraphicsMagick++.a -L/usr/ports/lang/llvm-gcc4/work/llvm-gcc4.2-2.5.source/obj/i386-portbld-freebsd7.0/libstdc++-v3/src -L/usr/ports/lang/llvm-gcc4/work/llvm-gcc4.2-2.5.source/obj/i386-portbld-freebsd7.0/libstdc++-v3/src/.libs -L/usr/ports/lang/llvm-gcc4/work/llvm-gcc4.2-2.5.source/obj/./gcc /scratch/bfriesen/build/GraphicsMagick-16-static-llvm/magick/.libs/libGraphicsMagick.a -llcms /usr/local/lib/libtiff.so -ljbig /usr/local/lib/libfreetype.so /usr/local/lib/libjasper.so /usr/local/lib/libjpeg.so -lpng /usr/local/lib/libwmflite.so /usr/local/lib/libXext.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libX11.so /usr/local/lib/libxcb.so /usr/local/lib/libXau.so /usr/local/lib/libXdmcp.so /usr/local/lib/libpthread-stubs.so -lrpcsvc -lbz2 /usr/local/lib/libxml2.so /usr/local/lib/libiconv.so -lz -lpthread /usr/local/lib/llvm-gcc-2.5/libstdc++.so -lm -lgcc_s /usr/local/lib/llvm-gcc-2.5/libgomp.so -pthread -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib/llvm-gcc-2.5 -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/lib/llvm-gcc-2.5 Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/// This may look like C code, but it is really -*- C++ -*- // // Copyright Bob Friesenhahn, 1999-2010 // // Tests for throwing exceptions // #include Magick++.h #include string #include iostream using
Re: libtool, llvm-gcc, failing C++ exceptions
Hi Bob, * Bob Friesenhahn wrote on Tue, Jan 05, 2010 at 05:11:56PM CET: Using 'llvm-gcc' (GCC frontend to llvm compiler) I find that C++ exceptions do not work (are not caught) in the built programs. When building C++ programs and libraries, libtool tells the compiler to not supply its own runtime or libraries, and then specifies what it believes are the correct runtime and libraries. Over the years I have encountered a number of cases where C++ exceptions don't work, and llvm-gcc (as provided with FreeBSD) is an example. Another case is with 64-bit code on AMD64 Solaris 10 where C++ exceptions don't work in GCC-built code (but they do work with the Sun compiler). An identical problem was reported in 64-bit AMD64 code under FreeBSD 7.2. Unfortunately, this is a complex problem because sometimes the C++ exceptions stop working after a large body of code (e.g. GraphicsMagick + libtiff + ) has been linked into it. It has something to do with process initialization. While it has not been proven yet, I am suspecting that the failing C++ exceptions have something to do with the way that libtool links these modules. Does anyone have ideas about this? Try to find out if exceptions work when you manually override what libtool does. My first guess would be that only library linking is wrong, but not program linking. In an up to date build tree of GM: rm magick/libGraphicsMagick.la env RM=echo make magick/libGraphicsMagick.la then copy and paste the link command line, adjust it the way you think it should have looked instead, and run it. Let's hope the $RM override keeps all required intemediate files for you. Then rebuild a program that uses this library. Does exception handling work now? You may have to rinse and repeat with other suspected-broken libraries. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
