Re: binutils prerelease mark 2 available for testing (feedback needed)

[Charles Wilson <cwilson at ece dot gatech dot edu>]

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@sourceware.cygnus.com