[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ld-output-def
From: |
Bruno Haible |
Subject: |
Re: ld-output-def |
Date: |
Wed, 1 Apr 2009 01:45:44 +0200 |
User-agent: |
KMail/1.9.9 |
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