[Top][All Lists]

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

Re: dll compile, can not resolve with -module libs

From: Robert Collins
Subject: Re: dll compile, can not resolve with -module libs
Date: Fri, 22 Jun 2001 22:55:58 +1000

----- Original Message -----
From: "Guido Draheim" <address@hidden>
To: <address@hidden>
Sent: Wednesday, June 20, 2001 3:04 AM
Subject: dll compile, can not resolve with -module libs

> As everyone knows, compiling a win-dll requires all references
> to be resolved at link-time, and therefore libtool needs to
> know all lib-files by their name in the link-stage.
> A project of mine contains a few module-dll that are installed
> into $pgklibdir and "dlopen"-ed. Now there is a module2-dll that
> needs a few functions from another module1-dll, no problem you
> might think, just add it to the list of link-dependencies.
> The answer is, there is no way to do it - libtool will check
> each of the linked libraries in a file_magic-stage, and it will
> strictly expand all -l$what into a search for a thing called
> lib$what[.-]* - it does not even check for a "/" in the "-l"-arg,
> nor is it ready to recognize a module-sharedobject anyway as
> it will always add the "lib"-prefix - the "ls -ld"-call will
> even try  b*llsh*t like "ls -ld lib.libs/module[.-]*"
> This -module related problem is a no-issue in ldso-based systems
> where we can just omit the dependency of to
> during link-time, the dlopen()-call would just return an errorcode
> if was not loaded before - it isn't in a
> dll-compile as the dll-table of module2.dll must know about
> module1.dll, but the file_magic check can not see module1.dll.
> How to go from here?
> (currently using cross-compiler linux->mingw32msvc)

if you add the module .la file to the link line for module1 it should
work ok (because it will get the library name from the .la file, not by
guessing). I think there's something similar in the libtool tests.


reply via email to

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