Re: Disable --whole-archive when using convenience archives
On Thu, Jan 7, 2010 at 10:10 PM, Ralf Wildenhues wrote: > * Alon Bar-Lev wrote on Thu, Jan 07, 2010 at 09:07:46AM CET: >> > For some strange reason this workaround does not work in Windows when >> > creating a DLL. >> > >> > I get: >> > --- >> > /bin/sh ../../../../libtool --tag=CC --mode=link >> > x86_64-w64-mingw32-gcc -g -O2 -pedantic -Wall -Wextra -module >> > -shared -avoid-version -no-undefined -export-symbols x.exports -o x.la >> > -rpath /tmp/xxx/lib x.lo ../../../../src/lib/core/libcore.la -lws2_32 >> > >> > *** Warning: This system can not link to static lib archive >> > ../../../../src/lib/core/libcore.la. >> > *** I have the capability to make that library automatically link in >> > when >> > *** you link to this library. But I can only do this if you have a >> > *** shared version of the library, which you do not appear to have. >> > *** But as you try to build a module library, libtool will still create >> > *** a static module, that should work as long as the dlopening application >> > *** is linked with the -dlopen flag to resolve symbols at runtime. >> > --- >> > >> > If I modify libtool: >> > if test "$deplibs_check_method" != pass_all; then >> > To: >> > if false && test "$deplibs_check_method" != pass_all; then >> > >> > It works... > >> Any idea how to workaround/solve this on windows host? > > I'm not sure I understand correctly. libtool prints a warning, but > should not fail. Is the result usable? If not, then the build should > end with an error in a later link: can you post it and its output? > > Thanks, > Ralf > Here it is: liba - should be static libb - should be dynamic, liking with liba without whole archive. Works on UNIX does not on Windows. Attached are the sources. Thanks, Alon. --- make all-am make[1]: Entering directory `/home/alonbl/tmp/xx/libtool' /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c -o b.lo b.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -DDLL_EXPORT -DPIC -o .libs/b.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT b.lo -MD -MP -MF .deps/b.Tpo -c b.c -o b.o >/dev/null 2>&1 mv -f .deps/b.Tpo .deps/b.Plo /bin/sh ./libtool --tag=CC --mode=compile i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -prefer-pic -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c -o liba_la-a.lo `test -f 'a.c' || echo './'`a.c libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -DDLL_EXPORT -DPIC -o .libs/liba_la-a.o libtool: compile: i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -g -O2 -MT liba_la-a.lo -MD -MP -MF .deps/liba_la-a.Tpo -c a.c -o liba_la-a.o >/dev/null 2>&1 mv -f .deps/liba_la-a.Tpo .deps/liba_la-a.Plo /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -prefer-pic -g -O2 -rpath /usr/local/lib -static -o liba.la liba_la-a.lo libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries libtool: link: i686-w64-mingw32-ar cru .libs/liba.a liba_la-a.o libtool: link: i686-w64-mingw32-ranlib .libs/liba.a libtool: link: ( cd ".libs" && rm -f "liba.la" && ln -s "../liba.la" "liba.la" ) /bin/sh ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -g -O2 -module -shared -avoid-version -no-undefined -export-symbols ./libb.exports -o libb.la -rpath /usr/local/lib b.lo liba.la *** Warning: This system can not link to static lib archive liba.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. libtool: link: i686-w64-mingw32-ar cru .libs/libb.a .libs/b.o libtool: link: i686-w64-mingw32-ranlib .libs/libb.a libtool: link: ( cd ".libs" && rm -f "libb.la" && ln -s "../libb.la" "libb.la" ) make[1]: Leaving directory `/home/alonbl/tmp/xx/libtool' libtool-whole.tar.bz2 Description: BZip2 compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool, llvm-gcc, failing C++ exceptions
* 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. > Over the years I have encountered a number of cases where C++ > exceptions don't work, Do you use dlopened modules? If yes, try adding -export-dynamic to the link flags of the program, and try enabling global symbol resolution for opened modules. I'll post a testsuite addition on libtool-patches to try out. Do you mix C++ code with other code, e.g., code compiled with the C compiler? Some non-GCC compilers may need other switches for exception handling to work right, e.g., +eh for the HP-UX compiler. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Are we close to a 2.2.8 release?
Hello Neil, * Neil Jerram wrote on Thu, Jan 07, 2010 at 10:35:08PM CET: > If a 2.2.8 release is expected quite shortly, I could adjust my > schedule to wait for it and do something else first. But if it is > still some months away, I will probably look at making my own build > from Git. So... do you have a schedule for the 2.2.8 release? No. We would like to release it soonish, esp. since the last release from master has been quite a while ago (2.2.6b was spun right off of 2.2.6a); but we do not make promises. > (And, > I guess, am I correct in assuming that it will include this fix?) Yes. > Also, if I decide to build from Git, is there any particular > instability anywhere in master that would recommend taking a tree just > before that? Take git master. We try to keep master as stable as possible. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Are we close to a 2.2.8 release?
2010/1/9 Ralf Wildenhues : > Hello Neil, > > * Neil Jerram wrote on Thu, Jan 07, 2010 at 10:35:08PM CET: >> If a 2.2.8 release is expected quite shortly, I could adjust my >> schedule to wait for it and do something else first. But if it is >> still some months away, I will probably look at making my own build >> from Git. So... do you have a schedule for the 2.2.8 release? > > No. We would like to release it soonish, esp. since the last release > from master has been quite a while ago (2.2.6b was spun right off of > 2.2.6a); but we do not make promises. Understood. >> (And, >> I guess, am I correct in assuming that it will include this fix?) > > Yes. > >> Also, if I decide to build from Git, is there any particular >> instability anywhere in master that would recommend taking a tree just >> before that? > > Take git master. We try to keep master as stable as possible. Many thanks for your clear answers. Neil ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool mail lists
Hi libtool webadmin, This page http://www.gnu.org/software/libtool/ currently refer to site "http://mail.gnu.org/";... for libtool related mail lists . It seems to that correct site is "http://lists.gnu.org/...";. Also not all links point to final location as example "http://lists.gnu.org/pipermail/libtool-patches/"; (note s/mail/lists/ ) it moved permanently to href="http://lists.gnu.org/archive/html/libtool-patches";. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool, llvm-gcc, failing C++ exceptions
On Sat, 9 Jan 2010, Ralf Wildenhues wrote: * 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. Over the years I have encountered a number of cases where C++ exceptions don't work, Do you use dlopened modules? If yes, try adding -export-dynamic to the link flags of the program, and try enabling global symbol resolution for opened modules. There is the option to use dlopened modules, but the problem also occurs in a static build. Do you mix C++ code with other code, e.g., code compiled with the C compiler? Some non-GCC compilers may need other switches for exception handling to work right, e.g., +eh for the HP-UX compiler. There is of course C code in the equation. I don't know how to avoid that. C++ exceptions are not being thrown across/through C code. Exceptions are working fine with the HP-UX compiler. The only compilers where I have seen C++ exception problems are ones which are either GCC or using GCC's front-end (like llvm-gcc). The issue may or may not be related to libtool. 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 mail lists
Hi Roumen, * Roumen Petrov wrote on Sat, Jan 09, 2010 at 04:33:00PM CET: > This page http://www.gnu.org/software/libtool/ currently refer to > site "http://mail.gnu.org/";... for libtool related mail lists . It > seems to that correct site is "http://lists.gnu.org/...";. > > Also not all links point to final location as example > "http://lists.gnu.org/pipermail/libtool-patches/"; (note > s/mail/lists/ ) it moved permanently to > href="http://lists.gnu.org/archive/html/libtool-patches";. These should be fixed now. Thanks for reporting them! Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
