No. __declspec(dllimport) tells the compiler that an indirection is
needed. The compiler will simplify '&externvar' to '_imp__externvar'.
There is one _imp__externvar per library, but all their values are the
same.
The "same function name, different address" problem will occur - as far
as I understand it - when you don't use __declspec(dllimport) for
functions.
This is the case when the linker adds trampoline functions looking like:
_externfunc:
jmp *__imp__externfunc
(This case was also a headache in the ELF/IA-64 glibc implementation.)
==================
As far as i know this isn't really true for functions. The function
trampolines get generated in the import library on windows (cl) so they
are allways present, even if you don't specify dllimport, and they also
get used allways if they are present at link time. Other than this is
with data, where the trampolines get generated at link time in the
resulting binary image.
This means that for functions there is absolutely no problem exporting
automatically by generating a def file for example (and importing works
automatically), but with data one allways needs the
__declspec(dllimport) for the trampoline to get generated (export can be
done via def file too).
I'm currently writing wgcc v2 which implements all this (only dllimport
for data is needed anymore, all other __declspecs can be omitted, since
all stuff gets generated (a def file, and some .asm code).
Cheers, Markus
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
