Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Date: Wed, 3 May 2000 13:40:25 +0300
From: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
Reply-To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
Message-ID: <1569.000503@is.lg.ua>
To: DJ Delorie <dj AT delorie DOT com>
CC: cygwin AT sourceware DOT cygnus DOT com
Subject: Re[2]: Status of availability of features which allow correct and seamless support of DLLs in current GNU-Win32 releases
In-reply-To: <200005010424.AAA32525@envy.delorie.com>
References: <200005010424 DOT AAA32525 AT envy DOT delorie DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello DJ,

Monday, May 01, 2000, 7:24:00 AM, you wrote:


>> 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.

DD> More of a convenience to people migrating from unix.

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

DD> Yup.  Early version.  Grows more each revision, we hope.

    Sorry, I don't understand this. Is there any changes was done
to ld on this matter since  1999-08-18 or is it supposed that they
will be done?

>> 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.

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

    This is for sure not linker job ;-)

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

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

    If I will put data symbols in defs myself for every X-Server,
GNOME, KDE, etc. which I'm going to port, I will hardly port single.
Which is exactly the current situation ;-)

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

DD> How so?

    Strange, it seems to be really nondeterministic bug. I deleetd
original testcase and was unable to re-make it %) However, failing to
get rid of ordinals easily produced me broken stuff with more
realistic example, one of the libtool demos: there 4 related dlls
built, first was built ok, but just second failed. Objdump's output
diff between correct and broken dll follows:

----
*** l2  Tue May  2 23:00:20 2000
--- E:\Projects\libtool-w32\a\l2        Tue May  2 23:00:16 2000
***************
*** 75,81 ****
  The Export Tables (interpreted .edata section contents)

  Export Flags                  0
! Time/Date stamp               390f5bee
  Major/Minor                   0/0
  Name                          0000303c libl2.dll
  Ordinal Base                  1
--- 75,81 ----
  The Export Tables (interpreted .edata section contents)

  Export Flags                  0
! Time/Date stamp               390f5ad2
  Major/Minor                   0/0
  Name                          0000303c libl2.dll
  Ordinal Base                  1
***************
*** 88,99 ****
        Ordinal Table                   00003038

  Export Address Table -- Ordinal Base 1
!       [   0] +base[   1] 1054 Export RVA
!       [   1] +base[   2] 2000 Export RVA

  [Ordinal/Name Pointer] Table
!       [   0] func_l2
!       [   1] var_l2


  PE File Base Relocations (interpreted .reloc section contents)
--- 88,99 ----
        Ordinal Table                   00003038

  Export Address Table -- Ordinal Base 1
!       [   0] +base[   1] 2000 Export RVA
!       [   1] +base[   2] 1054 Export RVA

  [Ordinal/Name Pointer] Table
!       [   0] var_l2
!       [   1] func_l2


  PE File Base Relocations (interpreted .reloc section contents)
----

    Nothing illegal: just have names swapped, as well as ordinals.
However, second fails to load on ogiginal win95.

   Binary differences consistent with picture above and doesn't have
other deviations. I don't have mood to investagate further: after
all, ordinals are win32 idiosyncrasy and hence represent only academic
interest. I may however make guess why dlltool-generated dlls (export
tables) don't have that problem: it did not support DATA, it does not
support aliases: then who told it supports any attribute at all ;-)

[]

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

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

    Such rule would be nice for msvc manual, but hardly for gcc's.
Whole talk about porting stuff to win32, not writing own. It was
possible to write own dlls yet with gcc 2.8.1 which at all didn't
support __declspec's, with that #define var (*__imp_var) (or as I did
it: I hacked dlltool to produce prefix-less symbols in implib and then
compiled in C++ mode and used references - nice, er? ;-) ). But
finally it's possible to do it the way vendor set as rule. But that's
not stop, but rather starting point to give up those __declspecs at
all. If Unix lives without them, win32 will live also. Period. ;-)


Best regards,
 Paul                            mailto:paul-ml AT is DOT lg DOT ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com