Re: ld-auto-import documentation update

[Christopher Faylor <cgf at redhat dot com>]

On Fri, Dec 27, 2002 at 11:18:48AM +0100, Ralf Habacker wrote:
>>But this does not depends on using import libraries.  Renaming symbols
>>with a def file affect the dll too and could be used without import
>>library.
>
>>>Are there other ways to accomplish this by standing on our heads and
>>>using defines?  Probably?  Do we want to change Cygwin to use these
>>>other methods?  No.
>
>Now I have heard two times, that you don't want to change cygwins
>implementation of how generating the exporting symbols.  It's your
>responsibility and I respect this, but you haven't answered about the
>distinction beetwen using def files in relation to using import
>libraries.

Will this thread never die?  Every time I think it is close to going
away, it is resurrected again.  I can appreciate your enthusiasm for
your changes, Ralf, but I think it is nearly time to give it a rest.

Unfortunately, I can't precisely respond to "the distinction between
using def files in relation to using import libraries", since I don't
know what you are talking about.

To explain how Cygwin uses def files: Cygwin uses def files to precisely
control what is exported.  It can't export every single global that it
uses and the cygwin sources don't mark all of the appropriate globals
with dllexport.  So, a .def file is a nice way to define what a user is
supposed to see.  If we did away with the .def file and used
--export-all-symbols, I can only imagine that the size of the dll would
grow noticeably with hundreds of extra global symbols.  More
importantly, the majority of globals available in cygwin should
absolutely not be exposed to the user since, 1) they would pollute the
user's name space, and 2) calling them could completely screw up a
program.

I don't know if this is what you are asking or not, but, if you are, I
have to wonder why all of this isn't already obvious to you.

As to why one couldn't just link with 'cygwin1.dll' rather than
libcygwin.a, I've already mentioned that libcygwin.a is a mixture of dll
info and other non-dll objects.  Egor Duda just introduced another non-dll
resident function very recently, in fact.  If you are asking why I can't
just split things out into a static library and use that with a combination
of the DLL itself, the answer, again, should be fairly obvious.  It would
make cygwin's "libc.a" unlike any other and it would require changes to
gcc.  Since it requires changes to gcc, this means that we'd either need
to maintain some kind of backwards compatibility libraries or we'd have
to force everyone to upgrade to a new version of gcc after a new cygwin
release.

I've also already mentioned that cygwin effectively renames some
exported symbols in the .def file.  Why it does this is immaterial,
given that we still need a .def file, anyway.  FWIW, cygwin also uses
the alias attribute in a few places for unrelated reasons, so, obviously
someone (i.e., I) was familiar with the concept.

So, there is no benefit to changing the status quo in cygwin.  I'm
satisfied with link speeds in cygwin and maintaining a separate
libcygwin.a is absolutely no hardship after all of these years.  Nothing
is broken so nothing needs to be fixed.

I don't see why you think you need my buyin for the cygwin dll, anyway.
Your changes are in.  You just can't point to the cygwin dll as an
example of their use.  That's not a big deal.

cgf