bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]