On 9/24/2010 2:46 PM, Peter Rosin wrote: > Now I'm also confused. That's not good.
> /me double checks (see below) > > WHAT? It doesn't work as I stated!?! > > *ponders that for a bit* > *scratches head* > > Ahh, you said "libtool does this by default IIRC". If that's actually the > case than that is what has have me fooled for years. Pay close attention to how libtool compiles (the single, only) main.o. Does it get the picflag (-DDLL_EXPORT) or not? As I've always understood it, *without* auto-import magic, you MUST have the following: 1) shared: a) a dll, compiled with declspec(dllexport) [or, create the DLL with an explicit .def file listing the exported symbols] b) the client *must* be compiled with declspec(dllimport) decorators on all symbols the client wants to use from the DLL 2) static a) a lib. Nothing should be compiled with declspec(dllexport), and obviously there is no .def file involved b) the client must NOT be compiled with declspec(dllimport) -- because then you get the missing __imp__foo error. So, your test case below doesn't surprise me. What DOES surprise me, is that it ever worked at all with MSVC (or gcc + -disable-auto-import), since it appears that Ralf is correct and the *_PROGRAM objects are built in only one "mode". Whether that is "picflag" (-DDLL_EXPORT) or not, one or the other linking modality should fail (static linking if main.o is compiled with -DDLL_EXPORT; dynamic linking if main.o is NOT compiled with -DLL_EXPORT). So, yeah, I'm a little confused as well. I think you need to do some archeology on the *_PROGRAM objects (nm -B or whatever the equivalent is in msvc land), and figure out what symbols are undefined. I'd take a hard look at demo/. NOTE: Bruno Haible's method worked around this by ALWAYS defining symbols in a library as declspec(dllimport), when building the library shared, building the library static, OR building a client. BUT...to make linking the DLL itself work (with internal references to these "dllimported" symbols!), he uses some nm and asm magic to (a) manually define the __imp_* redirection symbol values and set them to point to the address of the actual symbol, and (b) explicitly export each "exported" symbol using an asm .drective, even tho it was marked dllimport. It's really rather clever, but I've never really figured out how to merge it into the typical auto*/libtool process (Bruno's libiconv and gettext do it, but with a lot of Makefile.am hackery). Second, I don't know if it would work with MSVC easily; certainly the asm magic would need modification. Third, it almost *requires* to build *everything* with --disable-auto-import. Which would NOT go over well with the larger community. So, I've never pursued it, and obviously Bruno hasn't pushed the issue. > *deep sigh* > > Thanks for setting me straight. > > What now? Is the patch still good? (with a reworded changelog of course) Well, I think so. It's possible we might need a follow-on patch for "strict correctness" -- but this patch appears to be correct as far as it goes. > But now I'm really confused. What made the original patch work? It had > "#define EXTERN extern __declspec(dllimport)" unconditionally for MSVC. > And that patch also had two SKIPs and one FAIL (libfoo.a vs. foo.lib). > I.e. the exact same result, which means I can't be completely wrong. Or > is the testsuite not doing any static builds? But that seems highly > unlikely indeed. WTF? Look really closely at how hell_static.exe is built in demo/. But, to sum up, I see no problems with THIS patch, as far as it goes. With regards to Ralf's question re: _MSC_VER. Well, technically you'd probably be "more" correct to do: #if (defined(_WIN32) || defined(_WIN32_WCE)) && !defined(__GNUC__) ... rather than _MSC_VER; that formula would indicate "any win32 or wince platform, using any compiler EXCEPT gcc" -- because only gcc has "auto-import" on win32. But nobody does that; pretty much all source code with pretensions of both cross-platform use, AND windows support, uses _MSC_VER (*badly* ported code uses _WIN32 to mean "MSVC" which causes no end of cygwin and mingw headaches!). Because of that, IIUC most users of "other" compilers for win32 (Intel C/C++, Watcom, Borland, etc) either (a) routinely s/_MSC_VER/__WATCOMC__/g, or (b) add -D_MSC_VER anyway. -- Chuck
