Hi Simon, > 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?
Without the -symbol- infix, 'lib-versions' makes me think about the library versions (a.k.a. library soname) and libtool's versioning scheme; this is about the library as a whole. We have module names longer than that already: posix_spawn_file_actions_addclose relocatable-prog-wrapper useless-if-before-free lib-symbol-visibility > What about: > > ld-version-script -> lib-versions > visibility -> lib-visibility > ld-output-def -> lib-msvc-compat I still prefer it with '-symbol-' infix for the first two. > > "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. OK, now we know why your module is useful. Please please mention these alternatives and why they suck in the documentation. > > 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. I see them talking about various aspects of the tools and libraries, but nowhere about the .def files or lack of them. But anyway, that's only a minor point. The major point is the documentation. Bruno
