Re: Darwin & Dynamic modules

[Max Horn]

At 3:28 Uhr +0200 15.09.2001, Guido Draheim wrote:
> Max Horn wrote:
> >  OK, I think I  just found out that this is the reason modules are not
> >  built right on darwin:
> >
> >  # Commands used to build and install a shared archive.
> >  archive_cmds="\$CC \$(test \\"x\$module\\" = xyes && echo -bundle ||
> >  echo -dynamiclib) \$allow_undefined_flag -o \$lib \$libobjs
> >  \$deplibs\$linker_flags -install_name \$rpath/\$soname \$verstring"
> >
> >  Changing the two \\" to \" worked nicely for me. Libtool, with this
> >  change, produces modules now when asked for them.
>
> it's an old bug - you may want to use this ac-macro to fix it in your project:
> http://ac-archive.sf.net/guidod/patch_libtool_on_darwin_zsh_overquoting.html

Well, it is not enough for me to just fix that in my own projects, to 
be quite frankly; since I am involved in porting dozens and dozens of 
apps, it would be nice if libtool itself would be fixed eventually :)

But thanks for that link, I'll check it out


> cvs libtool has a changelog entry that makes me assume that the zsh 
> overquoting problem has been solved somehow.

Only some cases it seem. I did a fresh libtool-head checkout and 
rebuilt, the problem ist still there :(


> (/bin/sh on darwin is usually a zsh)

Always, unless the user changes it manually. But I do not think this 
case has to be considered for now, nobody should ever change his 
/bin/sh (unless for extremly good reason) :)


> but I am not that sure about it. Others have to comment on that. 
> With the above patch tagged into configure.in (after the libtool 
> macros) makes the compilation  process to just do what it is 
> supposed to do - to create .so files. If you get
> to create .dylib's then please tell me how it can be done, okay? TIA...

Creating .dylib's works absoltuly fine for me with libtool-CVS 
(head). The problem was indeed that it would only make .dylibs, and 
never .so's :) (well, the extension was of course .so, but the file 
was not a loadable module but a shared lib).

Another thing that is buggy are conveniance libs, as reported in my 
previous mail (and this, too, seems to be a known issues, but that 
doesn't help me much :( - as I am one of those guys working on 
porting GTK to a quartz/MacOS X backend, I have the choice whether I 
want to apply the broken fix we have for this problem. Either I apply 
it, then one part of the compile breaks. Or I apply it not, then 
another part of GTK can't be compiled... <sigh>


Max
--
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:address@hidden>
phone: (+49) 6151-494890