[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shared library on MinGW
From: |
Ralf Wildenhues |
Subject: |
Re: Shared library on MinGW |
Date: |
Tue, 14 Mar 2006 13:17:00 +0100 |
User-agent: |
Mutt/1.5.11 |
Hi John,
* John Pye wrote on Tue, Mar 14, 2006 at 06:26:31AM CET:
>
> I just saw this thread and I have been experiencing similar problems.
> http://lists.gnu.org/archive/html/libtool/2006-03/msg00011.html
Well, if you have the same problem, then using `-no-undefined' should
fix it for you. ;-)
> What I'm doing is running a DLL (_ascend.dll) via Python (wrapped with
> SWIG). This DLL in turn needs to load some of its own DLLs for external
> plugin code.
At runtime, right? With LoadLibrary, or libltdl, or..?
> The external plugin DLLs contain unresolved symbols that are present in
> _ascend.dll and are supposed to be resolved at load-time. The symbols
> are involving in 'registering' the plugin back with the main
> application, and providing error reporting capabilities.
>
> Under Linux this all works fine. Under Windows, I can't make libtool
> compile my library with these unresolved symbols.
Right. Just won't work that way on Windows, though. You could factor
out all common code into a common library, for example. Or factor the
common code into a plugin. Or provide pointers for the callbacks.
I haven't tried the ideas listed on http://edll.sourceforge.net/ yet,
by the way. If they work, libltdl may benefit from integrating some
of them (optionally). If anybody has experience with them, I'd be
glad to learn about it.
Cheers,
Ralf