[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: |
Guido Draheim |
Subject: |
Re: dll compile, can not resolve with -module libs |
Date: |
Wed, 20 Jun 2001 03:32:44 +0200 |
okay, forget about that, I did resolve a few other problems
during libtool sequencing, and finally the "ld" does not
accept the module.dll as the cross-gcc's ld does also add
a "lib" at each "-l$name".. and can not find the module.dll
Now I have to rethink a few bits, like renaming the build-libs
apropriatly. It is interesting that we break windows'
name-conventions for libraries, happily adding "lib" before
the basename - am I right that this has changed from
former tools targetting windows?
okay, need some sleep now, bye, guido
Guido Draheim wrote:
>
> 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 module2.so to module1.so
> during link-time, the dlopen()-call would just return an errorcode
> if module1.so was not loaded before module2.so - 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)
>
> -- guido Edel sei der Mensch, hilfreich und gut
> 31:GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- h.r(*@)>+++ y++ 5++X-
-- guido Edel sei der Mensch, hilfreich und gut
31:GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- h.r(*@)>+++ y++ 5++X-
- dll compile, can not resolve with -module libs, Guido Draheim, 2001/06/19
- dll cross-compile, .libs/impgen is a win-exe, not a linux-binary, Guido Draheim, 2001/06/19
- Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary, Guido Draheim, 2001/06/19
- Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary, Olly Betts, 2001/06/20
- Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary, Guido Draheim, 2001/06/20
- Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary, Gary V . Vaughan, 2001/06/20
- Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary, Guido Draheim, 2001/06/20
- Re: dll cross-compile, .libs/impgen is a win-exe, not a linux-binary, Alexandre Oliva, 2001/06/21
Re: dll compile, can not resolve with -module libs,
Guido Draheim <=
Re: dll compile, can not resolve with -module libs, Robert Collins, 2001/06/22