On Jul 12 00:28:49, Marc Espie wrote: > On Wed, Jul 11, 2012 at 11:05:20PM +0200, Jan Stary wrote: > > On Jul 11 10:57:21, Marc Espie wrote: > > > Lots of fun last night and this morning. > > > > > > 1/ Turns out GNU libtool simply *removes* stuff it doesn't understand > > > while > > > linking. > > > > > > Case in point: libdns/ldns. It does link with > > > libtool link cc -o somelib --export-symbols lib.def someobj.o > > > > > > notice the --export-symbols, that's not a valid gnu libtool option (the > > > option is spelled -export-symbols). > > > So it gets ignored ! > > > > > > this did work by accident for us, since we used Getopt::Long which > > > doesn't care if it's --export-symbols or -export-symbols... > > > > > > when I fixed that, suddenly, we got some different behavior, so > > > our link stopped working. > > > > > > But I'll contend that's a fucking BUG in gnu libtool, since you can > > > just mispell something, and hey, watch it ! magic trick! it's gone !!! > > > > > > (that also explains why some ports require gnu libtool...
An example is audio/opencore-amr, which relies on USE_LIBTOOL=gnu
to remove linking options that otherwise make the build break:
With USE_LIBTOOL=yes, the linking fails with
libtool: link: cc -shared -fPIC -DPIC -o .libs/libopencore-amrnb.so.0.0
-I/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/oscl
-I/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/opencore/codecs_v2/audio/gsm_amr/amr_nb/dec/src
-I/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/opencore/codecs_v2/audio/gsm_amr/amr_nb/common/include
-I/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/opencore/codecs_v2/audio/gsm_amr/amr_nb/dec/include
-I/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/opencore/codecs_v2/audio/gsm_amr/common/dec/include
-I/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/opencore/codecs_v2/audio/gsm_amr/amr_nb/enc/src
-x c -std=c99 -O2 -pipe .libs/wrapper.o .libs/agc.o [LOTS OF *.o FILES]
-L.libs -lm
-Wl,-retain-symbols-file,/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/amrnb/opencore-amrnb.sym
.libs/wrapper.o:1: error: stray '\177' in program
.libs/wrapper.o:1: error: stray '\1' in program
.libs/wrapper.o:1: error: stray '\2' in program
.libs/wrapper.o:1: error: stray '\1' in program
[...]
Note the "-x c ... file.o"; it treats the *.o files as C source and fails.
This is a bug of the port, fixed with the attached patches.tar
Comments? OK?
Using USE_LIBTOOL=gnu makes this problem invisible
by simply removing all the options as described above by Marc,
including the '-x c'; the port builds fine then, but
only 'thanks' to this silly behaviour of libtool.
On Jul 12 01:31:56, Marc Espie wrote:
> so, ports that rely on this kind of broken behavior should be fixed.
> The port needs to be patched to stop passing stupid options to libtool link
> like that ! and that patch needs to go upstream.
Sent.
Jan
Index: Makefile
===================================================================
RCS file: /cvs/ports/audio/opencore-amr/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile 6 Jul 2012 17:21:11 -0000 1.1.1.1
+++ Makefile 12 Jul 2012 13:45:06 -0000
@@ -25,6 +25,6 @@ MASTER_SITES= ${MASTER_SITE_SOURCEFORGE
SEPARATE_BUILD= yes
CONFIGURE_STYLE= gnu
-USE_LIBTOOL= gnu # oh my.
+USE_LIBTOOL= yes
.include <bsd.port.mk>
patches.tar
Description: Unix tar archive
