|
From: | Benjamin Redelings |
Subject: | libtool rule for (windows) import lib from exe? |
Date: | Tue, 03 Dec 2013 13:14:50 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0 |
Hi, I'm trying to build plugins on windows that reference symbols in the main application. I've been told that the best way to do this is to build an import lib for your exe file, and then link your modules against the import lib to form DLLs. Is this recommended? I'm getting a warning message that implies I can dlopen *.a archives if I pass -dlopen to the linker for the main application. I am planning to use dlfcn-win32 to implement dlopen for the windows executable. On linux everything works, and I'm able to build *.so modules that I can load and call from dlopen. For mingw, everything builds, but libtool builds *.a files instead of *.dll files, with this warning: *** Warning: linker path does not have real file for library -lbali-phy.exe.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libbali-phy.exe.a but no candidates were found. (...for file magic test) *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module Range. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. I have two questions: (1) If the warning above is right, it looks like I do not need a DLL after all. Therefore I do not need to make an import library, I can just pass '-dlopen' as a linker flag when compiling the main application, and dlopen *.a files. Is this right on windows? (2) Could someone please help me find where the -dlopen flag is documented? Does this dlopen flag take an argument, like '-dlopen <file>'? If so, what is the file? (3) How can I write a libtool rule to construct the import library? Right now I have this: if HOST_LINUX bali_phy_LDFLAGS = -rdynamic else if HOST_MINGW32 bali_phy_LDFLAGS = -Wl,--export-all-symbols,--output-def,bali-phy.def else bali_phy_LDFLAGS = endif endif libbali-phy.exe.a: bali-phy.exe $(DLLTOOL) -dllname bali-phy.exe --def bali-phy.def --output-lib libbali-phy.exe.a (4) How can I tell libtool that the modules depend on the import lib? Right now I have something like:
if HOST_MINGW32 IMPORTLIB = -lbali-phy.exe.a else IMPORTLIB = endif mod_la_SOURCES = computation/builtins/mod.C mod_la_LDFLAGS = -module -shared -avoid-version -export-dynamic -no-undefined -enable-runtime-pseudo-reloc mod_la_LIBADD = $(IMPORTLIB) However, this produces the results above, where the modules are built as static *.a files instead of DLLs. Thanks so much for your help! -BenRI |
[Prev in Thread] | Current Thread | [Next in Thread] |