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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
