Re: Darwin & Dynamic modules

[Guido Draheim]

Max Horn wrote:
> 
> 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 :(
> 

I am not too deep into the prolem sphere - IIRC, it is a side effect
of newer autoconf-2.5x requoting and libtool.m4. If you could have
a go with newest autoconf, is it still there? If so, it's definitely
high time to fix it once and for all - sharedlib support on darwin 
has a good army of developers who badly need it to do proper developments
that do not fall short off other unixish environments.


> >(/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).

ho ho, that's an interesting fact - for about all systems I know so
far (and I am not that deep into darwin) the sharedlibs and dl-modules
are the same file format. Well, as you say it I remember some old info
about mach kernel modules specialties being somewhat like a driver
module on other systems - the dylibs are loaded by the kernel and not
a userspace library that opens dl-modules being called sharedlibs.

you see, I am not totally aware about the specifics of darwin, and I 
guess so are many others. The above ac-macro was developed with remote 
access to a darwin box, with the only goal to bring it to life, and 
that's just it. It has helped in between.

> 
> 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>
> 

you to make a new generation of libtool? I had too often seen that
libtool requires a specific version of .la files and references
helper libs to do its operation, so I guess it would be okay again 
to start another generation if there is no other help to it. It might
however need lots of talkback before everyone feels comfortable with
it, right? ;-)

anyway, I'll stick to comment on the first problem - it's more the
region I know about ;-)

cheers,
-- guido                                  http://guidod.4t.com
GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X-