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: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Message-ID: <01dd01c0f391$bbffb9c0$0200a8c0@lifelesswks> From: "Robert Collins" To: "Charles S. Wilson" , Cc: References: <3B2658CA DOT AFE25B71 AT ece DOT gatech DOT edu> Subject: Re: .def files, ordinals, and dlls Date: Wed, 13 Jun 2001 08:48:00 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 12 Jun 2001 22:37:47.0949 (UTC) FILETIME=[4E37BDD0:01C0F390] I've copied binutils in on this, as this is a ld issue more than a cygwin apps issue. ----- Original Message ----- From: "Charles S. Wilson" To: Sent: Wednesday, June 13, 2001 4:00 AM Subject: .def files, ordinals, and dlls > 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? Gulp. Uhmmm.. ouch. Yes, that's the right word, ouch. what does the import table of XEmacs show? > 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!!) Perhaps a bug in ld? > 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? :-) *blush*. I'm going to go now :]. More seriously I'm going to generate a testcase and see If I can trigger this with my hacked up libtool. Rob > > --Chuck >