Re: How to build a noinst_ but still shared library?
I didn't think convenience libraries were meant to result in shared libs, just a bucket of object files with a convenient handle. On Fri, Mar 19, 2010 at 7:35 PM, Dave Korn wrote: > >Hi all, > > Well, here I am again with another dumb n00b question. From the automake > manual: > > " Libtool convenience libraries are declared by directory-less > variables such as `noinst_LTLIBRARIES', `check_LTLIBRARIES', or even > `EXTRA_LTLIBRARIES'. " > > So: how do you build a shared library in your "make check" run, without it > ending up installed somewhere during "make install"? (In case it's > relevant, > the project is all flat in a single non-recursive Makefile, so I can't just > e.g. force the subconfigure in tests/ to use a bogus $prefix choice under > $objdir somewhere.) > >cheers, > DaveK > > > ___ > http://lists.gnu.org/mailman/listinfo/libtool > ___ http://lists.gnu.org/mailman/listinfo/libtool
relinking and cross-compiling
Hi, I'm using libtool in a project that builds a few shared libraries, a main program and plugins to the program, all in the same source package. I've made Debian style packages from my source tree, which requires installation into DESTDIR to work. In the native case, this works: /bin/sh ../libtool --mode=install /usr/bin/install -c interfaces.la '/srv/repo/build/sid/sge_0.0.20100322-1_amd64/debian/tmp/usr/lib/sge/backend' libtool: install: warning: relinking `interfaces.la' libtool: install: (cd /srv/repo/build/sid/sge_0.0.20100322-1_amd64/interfaces; /bin/sh /srv/repo/build/sid/sge_0.0.20100322-1_amd64/libtool --tag CXX --mode=relink x86_64-linux-gnu-g++ -g -O2 -fvisibility=hidden -module -avoid-version -no-undefined -o interfaces.la -rpath /usr/lib/sge/backend linux_network_service.lo plugin.lo network_service.lo ../libsge-agent.la -llazybox -inst-prefix-dir /srv/repo/build/sid/sge_0.0.20100322-1_amd64/debian/tmp) libtool: relink: x86_64-linux-gnu-g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtbeginS.o .libs/linux_network_service.o .libs/plugin.o .libs/network_service.o -L/srv/repo/build/sid/sge_0.0.20100322-1_amd64/debian/tmp/usr/lib -L/usr/lib -lsge-agent -llazybox -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crtn.o -Wl,-soname -Wl,interfaces.so -o .libs/interfaces.so libtool: install: /usr/bin/install -c .libs/interfaces.soT /srv/repo/build/sid/sge_0.0.20100322-1_amd64/debian/tmp/usr/lib/sge/backend/interfaces.so However, cross compiled packages fail here: /bin/sh ../libtool --mode=install /usr/bin/install -c interfaces.la '/srv/repo/build/sid/sge_0.0.20100322-1_armel/debian/tmp/usr/lib/sge/backend' libtool: install: warning: relinking `interfaces.la' libtool: install: (cd /srv/repo/build/sid/sge_0.0.20100322-1_armel/interfaces; /bin/sh /srv/repo/build/sid/sge_0.0.20100322-1_armel/libtool --tag CXX --mode=relink arm-linux-gnueabi-g++ -g -O2 -fvisibility=hidden -module -avoid-version -no-undefined -o interfaces.la -rpath /usr/lib/sge/backend linux_network_service.lo plugin.lo network_service.lo ../libsge-agent.la -llazybox -inst-prefix-dir /srv/repo/build/sid/sge_0.0.20100322-1_armel/debian/tmp) libtool: relink: arm-linux-gnueabi-g++ -shared -nostdlib /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/crti.o /usr/lib/gcc/arm-linux-gnueabi/4.3.2/crtbeginS.o .libs/linux_network_service.o .libs/plugin.o .libs/network_service.o -Wl,-rpath -Wl,/usr/arm-linux-gnueabi/lib -L/srv/repo/build/sid/sge_0.0.20100322-1_armel/debian/tmp/usr/lib -L/usr/lib -lsge-agent -L/srv/repo/build/sid/sge_0.0.20100322-1_armel/debian/tmp/usr/arm-linux-gnueabi/lib -L/usr/arm-linux-gnueabi/lib -llazybox -L/usr/lib/gcc/arm-linux-gnueabi/4.3.2 -L/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/arm-linux-gnueabi/4.3.2/crtendS.o /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/lib/crtn.o -Wl,-soname -Wl,interfaces.so -o .libs/interfaces.so /usr/lib/liblazybox.so: file not recognized: File format not recognized collect2: ld returned 1 exit status The problem here appears to be the "-L/usr/lib", which I suspect comes from $libdir. I'm not sure the "installed" $libdir should ever be searched for libraries, unless it also happens to be in the compiler's default path (which it is in the native case). If the "-L/usr/lib" is omitted, relinking works (the proper liblazybox.so is then found in /usr/arm-linux-gnueabi/lib). I can work around the problem by splitting the package, compiling the libraries separately and installing them before building the plugins (in this case, no relinking step is necessary). Simon signature.asc Description: Digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Disable --whole-archive when using convenience archives
Hello Ralf, It is find if you don't want to solve this, but please acknowledge that you don't. So far I did not get any response regarding this issue. When using: AM_CFLAGS = $(PCAP_CFLAGS) -prefer-pic AM_LDFLAGS = -rpath $(libdir) -static In order to make whole-archive go away, it works in *NIX but not in Windows. In order to fix it I need to modify libtool: elif test "$build_libtool_libs" = yes; then # Not a shared library - if test "$deplibs_check_method" != pass_all; then +if false && test "$deplibs_check_method" != pass_all; then Any chance this will be solved properly? Thanks, Alon. On Mon, Jan 25, 2010 at 6:12 PM, Alon Bar-Lev wrote: > On Sat, Jan 9, 2010 at 10:38 AM, Alon Bar-Lev wrote: >> 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 .l
