[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Darwin & Dynamic modules

From: Max Horn
Subject: Re: Darwin & Dynamic modules
Date: Sat, 15 Sep 2001 12:22:44 +0200

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:

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 (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 Horn
Software Developer

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]