Subject: Re: glib2 on OS X (buildlink3 and/or libtool 1.5 problem?)
To: Louis Guillaume <lguillaume@berklee.edu>
From: Dan Winship <danw@NetBSD.org>
List: tech-pkg
Date: 02/14/2004 15:55:12
--Apple-Mail-10--299335160
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Feb 13, 2004, at 1:45 PM, Louis Guillaume wrote:
> Hi Everyone,
>
> glib2 on OS X (10.3.2) fails with this...
>
> gcc -O2 -I/Volumes/Huevos/pkgsrc/devel/glib2/work/.buildlink/include  
> -Wall -o .libs/gobject-query gobject-query.o  
> ./.libs/libgobject-2.0.dylib  
> -L/Volumes/Huevos/pkgsrc/devel/glib2/work/glib-2.2.3/glib/.libs  
> /Volumes/Huevos/pkgsrc/devel/glib2/work/glib-2.2.3/glib/.libs/libglib 
> -2.0.dylib -L/Volumes/Huevos/pkgsrc/devel/glib2/work/.buildlink/lib  
> ../glib/.libs/libglib-2.0.dylib  
> /Volumes/Huevos/pkgsrc/devel/glib2/work/.buildlink/lib/libintl.dylib  
> /usr/lib/libiconv.dylib -lc
> ld: can't locate file for: -lglib-2
> gnumake[2]: *** [gobject-query] Error 1

Ugh. The problem is that buildlink3 is turning
     ../glib/.libs/libglib-2.0.dylib
into
     -L../glib/.libs -lglib-2
because it thinks the ".0" is part of a shared library version rather  
than being part of the library name. (And in fact, the complete library  
name is libglib-2.0.200.3.dylib, and there's really no way it can know  
that the ".0" is part of the library name and the ".200.3" isn't.)

I got glib2 to build by using the attached patch to  
pkgsrc/mk/buildlink3/gen-transform.sh, but I haven't tried building  
anything else to see if it breaks anything yet (or if anything breaks  
that this patch doesn't cover). It's also kind of a gross hack.

Another possibility might be to make libtool or something rename shared  
libraries on OS X so we'd have libglib-2_0 instead of libglib-2.0. That  
could also be gross though...

> Also I see a lot of "gcc: unrecognized option `-pthreads'" during the  
> build.

That's harmless. glib actually checks whether or not gcc supports the  
"-pthreads" flag, but OS X's gcc prints the warning and then just  
ignores it rather than exiting with an error code, so glib thinks it  
supports the flag and always passes it after that.

-- Dan


--Apple-Mail-10--299335160
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	x-unix-mode=0644;
	name="gen-transform.sh.txt"
Content-Disposition: attachment;
	filename=gen-transform.sh.txt

Index: gen-transform.sh
===================================================================
RCS file: /cvsroot/pkgsrc/mk/buildlink3/gen-transform.sh,v
retrieving revision 1.23
diff -u -r1.23 gen-transform.sh
--- gen-transform.sh	12 Feb 2004 20:29:34 -0000	1.23
+++ gen-transform.sh	14 Feb 2004 20:46:41 -0000
@@ -234,6 +234,7 @@
 s|\($2\)/lib\([^/$_sep]*\)\.so\.[0-9]*|-L\1 -l\2|g
 s|\($2/[^$_sep]*\)/lib\([^/$_sep]*\)\.so|-L\1 -l\2|g
 s|\($2\)/lib\([^/$_sep]*\)\.so|-L\1 -l\2|g
+s|\($2/[^$_sep]*/\.libs\)/lib\([^/$_sep]*\)\.dylib|-L\1 -l\2|g
 s|\($2/[^$_sep]*\)/lib\([^/$_sep]*\)\.[0-9]*\.[0-9]*\.[0-9]*\.dylib|-L\1 -l\2|g
 s|\($2\)/lib\([^/$_sep]*\)\.[0-9]*\.[0-9]*\.[0-9]*\.dylib|-L\1 -l\2|g
 s|\($2/[^$_sep]*\)/lib\([^/$_sep]*\)\.[0-9]*\.[0-9]*\.dylib|-L\1 -l\2|g

--Apple-Mail-10--299335160--