Hello Ralf,
> | Woe32 problem 1: Exports
> [...]
> | Methods 2b and 2c don't work for C++, because of the name mangling.
>
> Well, that assumes that you create an export list (or the asm
> statements) manually.
Yes, that's what I meant by "a selected set of symbols".
> That does not have to be the case: you
> could use a tool like `nm' or `dumpbin' to generate the lists.
> In fact, I believe libtool does something similar in some cases.
Yes, the user can specify a regex for the symbols. Does libtool demangle
the C++ symbols so that the user can write a regex that works independently
of the compiler's name mangling algorithm?
> | Method 2c additionally has the drawback that it works in a single
> | configuration only; a library cannot export different sets of symbols
> | depending on configuration settings.
>
> I don't understand this paragraph. You can create an export list
> in any way you like right before creating the DLL.
This paragraph is about a manually selected set of symbols. Sure you
can postprocess this export list right before creating the DLL. That
would be a fix to the mentioned drawback; you need extra processing
to eliminate this drawback.
> | Woe32 problem 2: Exported variables
> [...]
> | 4. Define a macro that expands to __declspec(dllimport) always, and
> | use it in all header files of the library that define variables.
> [...]
> | So, why isn't method 4 in wider use? The reason is that
> |
> | 1. the compiler signals warnings, making the developer think that he
> | is on the wrong path,
> | 2. libtool fails to handle self-references, i.e. references to a
> | symbol from within the shared library that exports the symbol lead to a
> | link error.
>
> If I have several code references using the symbol, each of them sees a
> declaration decorated with `__declspec(dllimport)', and takes the
> address of that symbol, then those pointers will compare equal only for
> code within the same library (or executable), right?
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.)
> > But currently, libtool lacks about 20 lines of code to make this approach
> > actually work.
>
> Well, with those 20 lines there's at least one practical issue:
>
> `join' isn't part of MSYS (yet), and neither listed in GCS:
> http://sourceforge.net/mailarchive/message.php?msg_id=17325152
> So we can't use it easily; or at least we should push for MSYS to
> include it.
Yes, this would be a good idea. It's not the first time that "join"
is needed to get down from O(n^2) to O(n). In the meantime one should
recode that statement to use 'sort' and 'sed'/'uniq' instead.
> I haven't understood yet how you think to deal with -export-symbols or
> -export-symbols-regex. Will the export ordinals remain constant if we
> use "the first attempt" to add the _imp__* pointers?
> ... library stability ...
I've no idea how GNU ld creates DLLs and what guarantees library stability
there. Experts?
> Next, there is existing software using method 3. Do I understand
> correctly that method 4 may be modified to detect this case and still
> support it?
When a software uses method 3, there are no self-references. The result
of the "join" command will be an empty file, and the generated exports.c
file will be empty. Hence it will work in this case too.
> Another point that comes to mind: mutually dependent libraries.
> With manually (i.e,. non-Automake generated) rules we could add a method
> to just extract the symbol lists/create the import libs, and create the
> dlls afterwards... not sure how to feed that into Automake, though,
> should we ever wish to support this there.
Scripts for creating mutually dependent libraries should indeed, if
they wish to use method 4, be prepared to filter out self-references.
But this is not an issue for libtool, since libtool on woe32 requires
the "-no-undefined" flag and therefore cannot be used to build mutually
dependent libraries.
Bruno
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
