Re: improve support for building DLLs on cygwin and mingw

[Ralf Wildenhues]

Hello Bruno, all,

First of all, let me thank you for all your work on this!  And apologies
in advance for a slightly unsorted list of thoughts in reply.

* Bruno Haible wrote on Mon, Sep 04, 2006 at 01:48:55PM CEST:
> 
> There are 4 ways to deal with the problem of exported variables when
> building shared libraries on Woe32 platforms. Programmers of shared libraries
> have to choose among them. Two of them I'd consider unacceptable for use
> in serious projects, and among the remaining two ways one is hard to put
> in place in projects that make use of gnulib.

Slightly related question: are you planning on providing a means to
automatically rename gnulib functions to a library-specific namespace?
As long as there is no policy on interface stability for gnulib, I would
fear to see lots of libraries floating around that all carry some
slightly incompatible version of some rather common symbol name around;
when such issues arise, they tend to be a pain to debug.

And what's more, I would guess that those symbols that come from gnulib
code are the most likely to benefit from _not_ being exported, at least
if the functions are not renamed and do not carry around any persistent
state: it helps avoid the incompatibilities that could arise from
different versions, as mentioned above.  (For functions with persistent
state, hidden-visibility could just be a different disaster.)

> You find complete details about this approach in
>   http://www.haible.de/bruno/woe32dll.html

Specific questions and comments to this document:

| 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.  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.
What am I missing?

| 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.  What am I missing?


| 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?  And if some other
code within the same library sees a non-decorated declaration of the
variable only (or before the decorated declaration), the pointer to it
will not compare equal, right?  (I guess this is what Danny is referring
to, too.)

> 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.  Alternativaly, we could use a slow shell emulation when
join is not present (yuck!).

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?  If I understand
this page correctly:
http://msdn2.microsoft.com/en-us/library/900axts6.aspx
then library stability (at least with MSVC) cannot be guaranteed unless
a .def file is used.  And if we support MSVC, then I'd at least like to
be able to provide this for those that happen to use a .def file.

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?

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.

> I don't suggest to add it to the linker (GNU ld), because I heard rumours that
> libtool shall in the long term also support the Microsoft compiler and linker
> ('cl'). Putting the support for this approach into libtool will also make it
> work with 'cl', whereas putting it into GNU ld would not.

Well, even if Libtool adds MSVC support: the linker should not need to
be dictated by Libtool.  But surely that is IMVHO, and for the binutils
folks to decide.

Last but not least, this looks like it's probably too intrusive for
branch-1-5 of Libtool, so in case you are working on a patch, that work
would be invested more productively against the HEAD version of Libtool.

Cheers, and thanks again,
Ralf