Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3B2658CA.AFE25B71@ece.gatech.edu>
Date: Tue, 12 Jun 2001 14:00:42 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: .def files, ordinals, and dlls
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

So here's a strange thing.  The XEmacs binary for cygwin from xemacs.org
was built against tiff-3.5.5-3.  However, xemacs.exe broke when
tiff-3.5.6beta-1 was installed, because the entry point "TIFFClientOpen"
could not be found (in the new dll). 

However, BOTH dlls, tiff-3.5.5-3 and tiff-3.5.6beta-1 contained that
symbol, just at different ordinal positions.  Both versions used the
same .def file, and did NOT specify "NONAME" -- so presumably, all
symbols were exported by name and ordinal, and xemacs *supposedly* was
linked "by name" -- the "supposed" default for ld.

There are actually two problems here:

1) why did XEmacs break -- obviously it's a link-by-ordinal problem
since both DLL's contained exactly the same symbol exports, just with
different ordinals.  But if ld "links-by-name" by default, then why did
this problem occur?

2) why did the two tiff packages, which both used the same .def file,
assign variant ordinals to the exports?  In some cases, the actual
ordinals in the dll's were DIFFERENT than those specified in the .def
file -- but 3.5.5-3 differed from the def file "differently" than
3.5.6beta-1 differed from the def file. (Got that?)  One possible clue:
there are 100 __declspec'ed exports, but the .def file specified only 75
of them.  Both dll's contained all 100 exports -- but not only were the
"extra" 25 exports differently assigned, but also the 75 .def'ed exports
were not assigned the same ordinals in the two dlls (which in some
cases, ALSO differed from the ordinal numbers EXPLICITLY given in the
.def file!!)

I worked around the problem by using objdump on the 3.5.5-3 dll, and
recreating a new .def file that specified all 100 exports.  I used this
new .def file in 3.5.6beta-2, and ended up with a dll that used the same
ordinals as 3.5.5-3 for all 100 exports.

Who was it that said ld's export behavior was deterministic? Was that
you, Robert? :-)

--Chuck