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
Message-ID: <397F395D.5015EA80@ece.gatech.edu>
Date: Wed, 26 Jul 2000 15:17:49 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
MIME-Version: 1.0
To: cygwin-apps AT sources DOT redhat DOT com
Subject: Re: Release binutils?
References: <20000726141303 DOT A30932 AT cygnus DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Faylor wrote:
> 
> Is someone looking into the ordinal problems in binutils?  Should I hold
> off releasing binutils until that is solved?
> 
> (I understand that ordinal problems are not a big deal and that
> the code still runs but it would be nice if our tools worked
> correctly.)

I took a look at the code, but I didn't really have the time to really
dig into it. I figured it wasn't a critical issue since stuff still
works.

According to Simon-Pierre Cadieux's investigations with *MSVC* as
reported on the png-developers list in May
(ftp://swrinde.nde.swri.edu/pub/png-group/archives/png-implement.0005)

> Conclusion. MS import libraries contain some type of information that
> specify whether name or ordinal value should be used. Which type is use
> depend if you export with __declspec(dllexport) or a def file respectively.

This begs the question: how does pe-dll.c do it (name or ordinal or
both?), when (1) creating an imp lib (2) linking an executable with an
imp lib (3) linking an executable using an implicit virtual implib. And,
how do the answers to those questions change (if they change) when
building the dll with  

(a) def file only
(b) __declspec only

(c) both __declspec and def file -- all symbols in def file are also
declspec'ed, all declspec'ed symbols are also in def file (set DECL ==
set DEF)

(d) both __declspec and def file -- some symbols declspec'ed but not in
def file but all symbols in def file declspec'ed (set DEF completely
contained by larger set DECL)

(e) both declspec and def file -- some symbols in def file are not
declspec'ed, but all decl_spec'ed symbols are in def file (set DECL
completely contained by larger set DEF)

(f) both declspec and def file -- some symbols are in def file but not
declspec'ed, some symbols declspec'ed but not in def file, some symbols
in def file AND declspec'ed (set DECL and set DEF overlap, but not
completely -- so that each contains unique items that are not in the
other set)

g) both declspec and def file -- some symbols are in def file but not
declspec'ed, some symbols declspec'ed but not in def file, and there are
no symbols that are both in the def file AND declspec'ed (set DEF and
set DECL are completely non-overlapping and each is nonempty)

Naturally, when linking an executable using a virtual import lib (case
#3 above) then few of the cases above (a) - (g) apply -- all you've got
to go on is the information in the dll since there is no true implib
that was created with __declspec and/or def files...unless Simon-Pierre
was wrong and the *dll* as well as the import lib contains instructions
about whether to link by name or link by ordinal...

After thinking about this a while, and realizing that --executables work
OK as is-- I decided that I would just let it be. Sorry for being a
slacker, but my prop is due soon...

As far as I am concerned, I think it's okay to go ahead and release
binutils now. Ordinals just don't seem that important; they'll get fixed
eventually but this issue isn't critical. To cygwin.

--Chuck