Re: Status of availability of features which allow correct and seamless support of DLLs in current GNU-Win32 releases

[DJ Delorie <dj at delorie dot com>]

> - One-pass link supported directly by ld, with standard -shared option
> enabling it.

If you mean for DLLs, yes.

> - Distinguishing between code and data symbols both when creating
> module definition file (def) from set of object files and when

Normally, you don't create a def from an object.  That's not the
linker's job.  It expects you to create the def files from scratch
(text editor), or with dllspec directives in the code.

> creating import library (implib) from def (as well as for one-step
> process, of course).

Yup.  Even at the same time.

> While ld -shared brings great convenience to building of dlls, it
> doesn't offer anything new technologically - all its functionality
> was supported before by dllwrap.

Right.  The latest linker should be much faster than dllwrap, which
just called the linker, dlltool, and other things.

> 1. ld is quite smart (thanks, DJ): when object files it links do not
> contain explicit dllexported symbols, it automagically exports all
> symbols, as if --export-all option were given.

More of a convenience to people migrating from unix.

> The problem here is that such case it doesn't export any data
> symbols

Yup.  Early version.  Grows more each revision, we hope.  There are
some problems with PE support in the current sources, so it's
difficult to incorporate new changes in the PE area before those are
addressed.

> Reason behind is understandable - using data symbols requires
> additional coping with them after dll was created, so let's pretend
> they don't exist at all.

Not really.  I just didn't get a chance to add it in the original
version.  Plus, the *right* way to do imported data is to modify the
header files (via dllspec), which exports them from the dll and
modifies the application to reference them properly at the same time.

> Failure here is that such policy disallow coping with data symbols *at
> all*.

You can't put them in the .def file yourself?

> However, ld when given def with ordinals (the way dlltool produces
> it), makes broken dlls.

How so?

> 2. There were reported pathological cases when ld -shared slower than
> dlltool %) .

But with common cases, it was six times faster than dlltool.

> 2. Dlltool does not support symbol aliasing option (onename=othername
> in def),

ld should.

> The general rule however is to produce def/implib from object files
> whenever possible.

The general rule is to generate imports from the source code, via
dllspec, or by hand-editing the def file.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com