Re: libtool 1.4 not passing linker directives
Well, I do realize that it's non-portable, but the number of platforms I'm building on is very restricted (the application is only of any real use on Linux systems running RPM, dpkg, and a few other special cases). I'm not really intentionally trying to use libtool; I'm just using automake, which told me to pass linker directives in the prog_LDADD variable, which I did, until it broke, and it seems that libtool 1.4 is what changes this behaviour. I'm not sure why it's using libtool to link my program -- is this necessary, avoidable? Ian On Sat, 2001-10-06 at 17:15, Peter Eisentraut wrote: Ian Peters writes: Yes, the end goal is to have all of the libraries between the -Bstatic and -Bdynamic linked statically, while keeping a dynamic binary against libc and ld-linux. You do realize that this goal cannot be portably accomplished, so you perhaps shouldn't use libtool? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
Ian: Automake uses Libtool to create libraries because it is portable, it's practially the only thing that is. One thing you should check, do you really have to specify what is static? I belive that under Linux, the linker will choose shared libs over archives, if that helps at all. Perhaps you could train your app to find only the archive libs at link time rather than add -Wl,Bstatic in your link line. Another alternative is to stop using Automake, just use the Makefile.in that you already generated, and tailor it to link with exactly the options you're hoping for. Did I miss anything? HTH, Rob Ian Peters wrote: Well, I do realize that it's non-portable, but the number of platforms I'm building on is very restricted (the application is only of any real use on Linux systems running RPM, dpkg, and a few other special cases). I'm not really intentionally trying to use libtool; I'm just using automake, which told me to pass linker directives in the prog_LDADD variable, which I did, until it broke, and it seems that libtool 1.4 is what changes this behaviour. I'm not sure why it's using libtool to link my program -- is this necessary, avoidable? Ian On Sat, 2001-10-06 at 17:15, Peter Eisentraut wrote: Ian Peters writes: Yes, the end goal is to have all of the libraries between the -Bstatic and -Bdynamic linked statically, while keeping a dynamic binary against libc and ld-linux. You do realize that this goal cannot be portably accomplished, so you perhaps shouldn't use libtool? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
Ian Peters writes: Yes, the end goal is to have all of the libraries between the -Bstatic and -Bdynamic linked statically, while keeping a dynamic binary against libc and ld-linux. You do realize that this goal cannot be portably accomplished, so you perhaps shouldn't use libtool? -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
On Fri, 2001-10-05 at 02:19, [EMAIL PROTECTED] wrote: On Fri, Oct 05, 2001 at 01:14:52AM -0400, Ian Peters wrote: Conspicuously missing are the linker directives to be passed to gcc, namely -Wl,-Bstatic and -Wl,-Bdynamic. I do this to produce a binary that is linked statically except for libc and the dynamic linker. Did you send the write output? I see -Wl,-Bstatic and -Wl,-Bdynamic in the output above. What's bad is their position has been reordered. What version of libtool are you using? I take it you want all libraries between -Bstatic and -Bdynamic statically linked? Whoops, you're right -- I only looked at the end of the output, I didn't look closely enough to notice they'd just been reordered, not stripped. Yes, the end goal is to have all of the libraries between the -Bstatic and -Bdynamic linked statically, while keeping a dynamic binary against libc and ld-linux. -- Ian Peters [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
On Fri, 2001-10-05 at 02:19, [EMAIL PROTECTED] wrote: What's bad is their position has been reordered. What version of libtool are you using? I take it you want all libraries between -Bstatic and -Bdynamic statically linked? Forgot to say, this has been tested with libtool 1.4 and 1.4.2. -- Ian Peters [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
On Fri, 2001-10-05 at 02:21, Tim Van Holder wrote: On Fri, 2001-10-05 at 07:14, Ian Peters wrote: Unfortunately, with libtool 1.4.x, I get this instead (after a much, much longer time): gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o [snip] installer-ui.o -Wl,-Bstatic -rdynamic -rdynamic -rdynamic -rdynamic -Wl,-Bdynamic ../libredcarpet/src/libredcarpet.a [snip] Conspicuously missing are the linker directives to be passed to gcc, namely -Wl,-Bstatic and -Wl,-Bdynamic. I do this to produce a binary that is linked statically except for libc and the dynamic linker. Clearly, they're not missing, but they do seem to have been overzealously grouped together at the start, with the change in results. Whoops, you're right. I didn't look at all of the command line close enough, I just assumed they'd been stripped. Is this a bug in libtool 1.4.x, or an undocumented change in behaviour? If so, is there some other way to accomplish the same goal? I'd say a bug, since options libtool doesn't handle itself are moved around when they shouldn't be. Suck, that was what I was afraid of. Any workarounds? -- Ian Peters [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool 1.4 not passing linker directives
On Fri, Oct 05, 2001 at 01:14:52AM -0400, Ian Peters wrote: An application I work on has been calling libtool (through automake) with linker directives on the libtool line, around many of the libraries specified, like so (apologies if this wraps strangely, it's all one line): /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o installer installer-distro.o installer-page.o installer-page-install.o installer-page-deps.o installer-page-finish.o installer-page-gdm.o installer-page-method.o installer-page-mirror.o installer-page-more-deps.o installer-page-proxy.o installer-page-select.o installer-page-start.o installer-state-machine.o installer-ui.o ../libredcarpet/src/libredcarpet.a ../libgnometransfer/src/libgnometransfer.a -Wl,-Bstatic -rdynamic -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/lib -lgtkhtml -lgal -lgnomeprint -lglade-gnome -lglade -lxml -lz -lgnomeui -lart_lgpl -lSM -lICE -lgtk -lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd -laudiofile -lm -ldb1 -lglib -ldl -lgnet -rdynamic -lgmodule -lglib -ldl /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgdk_pixbuf.a -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgnomecanvaspixbuf.a /home/itp/imlib-1.9.10//gdk_imlib/.libs/libgdk_imlib.a -ljpeg -ltiff -lungif -lpng -lz -lm -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -luuid -lcrypt -lz -lutil -Wl,-Bdynamic I see -Wl,-Bstatic -rdynamic -Wl,-Bdynamic With libtool 1.3.x, this resulted in the following call to gcc: gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o installer installer-distro.o installer-page.o installer-page-install.o installer-page-deps.o installer-page-finish.o installer-page-gdm.o installer-page-method.o installer-page-mirror.o installer-page-more-deps.o installer-page-proxy.o installer-page-select.o installer-page-start.o installer-state-machine.o installer-ui.o ../libredcarpet/src/libredcarpet.a ../libgnometransfer/src/libgnometransfer.a -Wl,-Bstatic -rdynamic -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/lib -lgtkhtml -lgal -lgnomeprint -lglade-gnome -lglade -lxml -lz -lgnomeui -lart_lgpl -lSM -lICE -lgtk -lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd -laudiofile -lm -ldb1 -lglib -ldl -lgnet -rdynamic -lgmodule -lglib -ldl /home/itp/gdk-pixbuf-0.11.0/gdk-pixbuf/.libs/libgdk_pixbuf.a -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm /home/itp/gdk-pixbuf-0.11.0/gdk-pixbuf/.libs/libgnomecanvaspixbuf.a /home/itp/imlib-1.9.10/gdk_imlib/.libs/libgdk_imlib.a -ljpeg -ltiff -lungif -lpng -lz -lm -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -luuid -lcrypt -lz -lutil -Wl,-Bdynamic Ditto. Unfortunately, with libtool 1.4.x, I get this instead (after a much, much longer time): gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o installer installer-distro.o installer-page.o installer-page-install.o installer-page-deps.o installer-page-finish.o installer-page-gdm.o installer-page-method.o installer-page-mirror.o installer-page-more-deps.o installer-page-proxy.o installer-page-select.o installer-page-start.o installer-state-machine.o installer-ui.o -Wl,-Bstatic -rdynamic -rdynamic -rdynamic -rdynamic -Wl,-Bdynamic ../libredcarpet/src/libredcarpet.a ^ ../libgnometransfer/src/libgnometransfer.a -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/lib /usr/lib/libgtkhtml.so /usr/lib/libgnomecanvaspixbuf.so /usr/lib/libbonobo.so /usr/lib/liboaf.so /usr/lib/libORBitCosNaming.so /usr/lib/libORBit.so /usr/lib/libIIOP.so /usr/lib/libORBitutil.so /usr/lib/libbonobox.so -lz -lXi -lXext -lX11 -lm -ldl /usr/lib/libgal.so /usr/lib/libgnomeprint.so /usr/lib/libgdk_pixbuf.so -ldl -lXi -lXext -lX11 -lm -lz /usr/lib/libglade-gnome.so -lXi -lXext -lX11 -lm -ldl -lz /usr/lib/libglade.so -ldl -lXi -lXext -lX11 -lm -lz /usr/lib/libxml.so -lz -lz -lz /usr/lib/libgnomeui.so -lm -lm -ldl /usr/lib/libgdk_imlib.so -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -lz -lm /usr/lib/libart_lgpl.so -lSM -lICE -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 /usr/lib/libgnome.so -lm -ldl -lz -lm /usr/lib/libgnomesupport.so -lz -lm /usr/lib/libesd.so -lm -lm /usr/lib/libaudiofile.so -lm -lm -lm -ldb1 -ldl /usr/lib/libgnet.so -lresolv -lnsl -ldl -ldl /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgdk_pixbuf.a -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm /home/itp/gdk-pixbuf-0.11.0//gdk-pixbuf/.libs/libgnomecanvaspixbuf.a /home/itp/imlib-1.9.10//gdk_imlib/.libs/libgdk_imlib.a /usr/lib/libjpeg.so -ltiff /usr/lib/libungif.so -lX11 -lpng -lz -lm /usr/lib/libgtk.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgdk.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgmodule.so -ldl /usr/lib/libglib.so -ldl -lXi -lXext -lX11 -lm
