Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <397DBE42.24D65658@ece.gatech.edu>
Date: Tue, 25 Jul 2000 12:20:18 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT sources DOT redhat DOT com
Subject: Re: binutils prerelease mark 2 available for testing (feedback needed)
References: <20000718234903 DOT 20211 DOT qmail AT web4605 DOT mail DOT yahoo DOT com> <200007190001 DOT UAA26173 AT envy DOT delorie DOT com> <20000718210045 DOT B14753 AT cygnus DOT com> <20000724122744 DOT A2193 AT cygnus DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Faylor wrote:
> 
> I've uploaded what I hope will be the next version of binutils here:
> 
> ftp://ftp.cygnus.com/private/cgf/binutils-20000722-1.tar.gz
> ftp://ftp.cygnus.com/private/cgf/binutils-20000722-1-src.tar.gz
> 
> Please give this a try and let the cygwin list know if there are problems.
> 
> This version has all of the patches that I've seen float by to correct
> the problem with the previous prerelease.

Well, it seems to basically work -- I've rebuilt all five libraries that
I've posted recently, and they all seem to work and pass their internal
tests.

However, I can unfortunately confirm Danny Smith's complaint, at least
in part:

> ld -shared (prerelease binutils-20000722-1) appears to ignore the
> ordinal values supplied in a .def when building dlls.

With zlib, the dll export ordinals are the same as that specified by the
.def file -- but, the def file (a) contains every function in the dll --
basically, an 'export-all' def-file, and (b) the functions themselves
are arranged in alphabetical order in the def file. I'm not sure if (a)
and/or (b) are relevant.

------

With libpng, the def file does not contain all the functions, and is not
in alphabetical order (although it's *close* to alphabetical). For some
reason, the dll exports additional functions not listed in the def file,
and the 'extra' exported functions are interspersed within the
'official' exports, bumping the ordinal numbers within the dll around.
The command used to build the dll:

gcc -shared -Wl,--enable-auto-image-base -o libpng.dll
-Wl,--out-implib=libpng.dll.a libpng.def png.pic.o pngset.pic.o
pngget.pic.o pngrutil.pic.o pngtrans.pic.o pngwutil.pic.o pngread.pic.o
pngrio.pic.o pngwio.pic.o pngwrite.pic.o pngrtran.pic.o pngwtran.pic.o
pngmem.pic.o pngerror.pic.o pngpread.pic.o  -L. -L/usr/lib -lz 

------

jbig -- same as zlib, originally. That is, alphabetical .def file, and
the def file exported everything. dependwalk showed that dll ordinals ==
def ordinals.

Then I got creative. I scrambled the .def file (but didn't leave out any
of the exports.) In that case, dependwalk showed that the dll ordinals
in the new dll == the new def ordinals.

So, it seems that the problem is these wacky 'extra' exports. 

New test: go back to the original, alphabetical .def file, and delete
three or four of the exports -- see what happens:

ARRGGHH. The ordinals in the new dll == the new def ordinals. No extra
exports. The functions that were removed from the def file are not
exported by the dll, even though they are marked with
__declspec(dllexport) in the code.

Okay, go back to libpng. What's wacky about it?

-------

AHA! Okay, one of the 'extra' exports is png_convert_to_rfc1123. That
symbol does NOT appear in the .def file. BUT, it is marked as
__declspec(dllexport) in the source code.  So, let's add all three of
the 'extra' symbols to the .def file.

  png_convert_to_rfc1123       @169
  png_init_io  @170
  png_set_invalid      @171

and rebuild the dll.

Double AARRGGHH. No change. The ordinals in the dll are scrambled w.r.t
the order specified by the .def file. Neither the dll ordinals nor the
.def ordinals are alphabetized.

I'm stumped. Sometimes ld -shared pays attention to the ordinals in the
def file (see jbig) and sometimes it does not.

Can someone enlighten me?

--Chuck

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