Bruno Haible <br...@clisp.org> writes: > Hi Simon, > >> How about this module? I use something similar in many of my projects. >> For an example of when a *.def file is useful, see "Using the GnuTLS DLL >> from your Visual Studio program" on <http://josefsson.org/gnutls4win/>. > > Again, I advocate for a module name that makes people understand when the > module is useful for them. 99% of the developers have never heard of the > ld option --output-def, therefore naming the module 'ld-output-def' will > not ring a bell. > > I proposed to rename > ld-version-script -> symbol-versions or lib-symbol-versions > and > visibility -> symbol-visibility or lib-symbol-visibility > > The purpose of this module here is to be compatible with Microsoft's > Visual C++ compilers, as I understand. So I how about calling this module > 'lib-msvc-compat' ?
That would be fine with me. I believe I agreed to renaming ld-version-script earlier as well. I kind of prefer the lib-* prefix because I think this is only ever relevant for libraries. That makes the name longer though. Do we need the -symbol- infix? What about: ld-version-script -> lib-versions visibility -> lib-visibility ld-output-def -> lib-msvc-compat If you agree, I'll rename ld-version-script and you can rename your visibility, and I can also propose a patch to do lib-msvc-compat. >> ... used to generate DEF files, >> +which can be useful for Windows users when they want to generate an >> +import library for your DLL. > > "can be useful"? Not always useful? It seems there are three ways to > deal with these .def files: > 1) Let the distributor of the DLL ship a .def file; this is what you > are advocating. Right. I think it is the simplest. > 2) Let the user create the .def file, using the Microsoft DUMPBIN > tool [1]. A) That involves manual work to convert the DUMPBIN /EXPORTS output format into a *.DEF file. B) The articles says it may not work with with DLLs generated with non-MS development tools. Thus it seems likely that there is some non-generic assumptions in the DUMPBIN approach. > 3) Let the user create the .def file, using the 'impdef' tool. [2] A) Impdef is not part of Visual Studio nor the GNU compiler suite, so the user needs to install additional tools. B) The page you cite says it is an unreliable process. > And 4) Let the user create the .def file, using the 'dlltool' command > from mingw. [3] A) dlltool is not part of the Visual Studio suite. B) Your reference [2] says that dlltool is the wrong tool for this job. C) It requires manual editing to convert from dlltool format to *.def format. > How do the approaches compare? I don't know how the implementations of these mechanisms compare though. There could be technical differences between these approaches, that leads to different contents of the *.def file. > I've been providing MSVC or mingw support in GNU libiconv for 8 or 9 > years now, and no one asked me for a .def file. I have to conclude > that the users were using approach 2) or 3). Searching for "libiconv windows visual studio" suggests that people build libiconv using MSVS instead and edit a *.def file manually [1], or use another iconv implementation [2]. There is one article which seems recent [3], but the links to the Windows port of libiconv isn't working, and it also suggests to build libiconv using MS tools. /Simon [1] http://xc2free.9.forumer.com/index.php?showtopic=7 [2] http://www.mail-archive.com/gnuwin32-us...@lists.sourceforge.net/msg01281.html [3] http://www.go-evolution.org/Building_Evolution_on_Windows#libiconv
