Re: ld-output-def

[Simon Josefsson]

Bruno Haible <address@hidden> 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/address@hidden/msg01281.html
[3] http://www.go-evolution.org/Building_Evolution_on_Windows#libiconv