Re: libtool "module" behavior and darwin

[Guido Draheim]

Benjamin Reed wrote:
> On Sunday, November 24, 2002, at 05:13 PM, Guido Draheim wrote:
>
> > I mean, that should also be seen on other platforms than darwin, right?
> > Or am I mistaken here? (I wouldn't count myself to know large parts of
> > libtool indepth, well, then again, who still does ;-) ...)
>
>
> Well, on pretty much every other platform nowadays, there's little (no?) 
> difference on-disk between a module and a regular shared library...  elf 
> doesn't care.  If you're dlopening it, it'll get found regardless.  In 
> darwin that's not the case... dlopen is emulated in the first place, but 
> the dynamic loader really acts nothing like dl on most other platforms.
>
> It may be that no one ran into this before because their platform wasn't 
> as strange as darwin.  =)

That's true from a system perspective - however, care to think of
"middleware platform"s that use "modules" in their own strange way.
Today, we can open win32 dlls on linux elf with the help of a
middleware platform like libwine/libavifile. IIRC, that's actually
the case on darwin where .so support is not provided by the
system but some postinstalled dlopen-package, right?

As in the other message, it sincerely depends on the notion whether
we should see "-module"s to be targetted always for a middleware
platform, and being *not* supposed to be linked into system binaries.
Well, on most systems, the most common middlware platform is a
system-provided dlopen()-facility. Is that really a different story?

If we make that strict, i.e. a module is for middleware platform,
then it might be also correct to strictly make *every* linking of
a system binary to a libtool archive to end up with the .a part
and *never* the sharedlib part - simply because that sharedlib is
not system but middleware centric. Always, even on elf where the
two are of the same kind, by luck.