[Top][All Lists]

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

Re: [Fink-devel] Re: libtool "module" behavior and darwin

From: Guido Draheim
Subject: Re: [Fink-devel] Re: libtool "module" behavior and darwin
Date: Mon, 25 Nov 2002 00:05:55 +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:44 PM, Guido Draheim wrote:

You mean they are listed as ".la" on the link-line?

To stick with the example, there is a
in your makefiles? aargh, kde maniacs at work....

No, it would be, libfoo_la_LIBADD = $(top_builddir)/kdecore/

How else would you link against a library that's not installed yet?

echo ' erocedkl- sbil./erocedk/)riddliub_pot($L- ' | rev
(I didn't say that, okay...)

Well, anyways, as in the other subthread: may be we'd instruct all
-module .la to be linked as .a, on all platforms, and leave all the
other .la be dynalinked. That would help here, and from my POV not
be incorrect on other platforms either. Hey, I may be wrong, so
what do others think?

Seems like no matter how "correct" it is, you'd be breaking (depending on your definition of breaking =) 95% of the platforms that it works on, just for the 5% where it doesn't...

for platforms, it might be 95%, for use cases it will not break anything
for the 999 that I have ever looked at - anyone to know the number 1000
where it would break things?

We're already used to working around the linker and (well, dyld) on darwin, since it's just plain odd. Seems silly to make modules unloadable on elf platforms just for us, when, to me, loading modules is a feature. It just happens to be a feature I don't have on Darwin. <g>

May I correct your wording hereon:
   Other systems allow to dlopen() system sharedlibs.

The current problem is the inverse of this:
   Linking dlopen()-modules into system binaries.

Both are strictly interdepent, right? IF that is the case THEN it is
bad behaviour of a programmer to actually TRY to link a dlopen()
module into a system binary since he makes a platform specific
assumption - being not portable at all. I think, libtool should not
warrant non-portable assumption, and instead enforce the only
portable assumption - as that -module sharedobjects should not be
part in a system link. Well, it didn't enforce it up to now, so...

reply via email to

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