[Top][All Lists]

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

Re: libtool "module" behavior and darwin

From: Guido Draheim
Subject: Re: libtool "module" behavior and darwin
Date: Sun, 24 Nov 2002 23:37:37 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

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.

reply via email to

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