Hi Chuck, I'm primarily trying to determine what impact this has on my MSVC branch...
Den 2009-01-03 02:39 skrev Charles Wilson: *snip*
+ *cygwin* | *mingw* | *cegcc* )
We should strive to have fewer of these in ltmain.m4sh, not more...
+ func_warn "Using fallback code to determine dllname for $1; consider updating binutils to version 2.20 (2.19.50.20081115), or newer."
I fail to find that version of binutils in Cygwin setup, so I guess the fallback code will get exercised. The comments say that "gcc" adds the dll name in .idata$7, and the fallback code makes use of this fact. How stable is that? What happens if you generate an import library late (if you only have the dll) with something that is not gcc? What if you have an import library created by e.g. MSVC? Looking at a few import libs in the Platform SDK suggests that MSVC uses .idata$6 instead. To me it seems as if the dllname is in the last .idata segment, can't that be scripted for a better fallback? Hmm, looking at the the --identify patch for binutils, it seems that it too simply dumps out .idata$7. That seems to be plain wrong for a whole bunch of import libs out there in the wild. Cheers, Peter
