Re: improve support for building DLLs on cygwin and mingw

[Bruno Haible]

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