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: <396CA424.CA1719EB@ece.gatech.edu>
Date: Wed, 12 Jul 2000 13:00:20 -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: Michael Ring <michael-ring AT t-online DOT de>
CC: cygwin-apps AT sources DOT redhat DOT com
Subject: Re: New version of bzip2 uploaded to sourceware
References: <9jlomsk2sk0qp6hkumfpovn69lipbi251e AT 4ax DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael Ring wrote:

> 
> HINT: There's also a .dll + bzip2-shared.exe included. Funny thing is,
> that it runs fine with a current snapshot, but stackdunps on an 'old'
> 1.1.2 installation. Chuck, rest of the world, any ideas ??
> 

Yup, stackdumps for me (uname -a = CYGWIN_NT-5.0 KHELDAR
1.1.3s(0.22/3/2) 2000-06-28 23:55 i686 unknown) e.g. June 28 snapshot.
The stackdump is pretty uninformative, though, because the binary is
stripped (as it should be, IMO), so I am not including it here.

A few comments (my opinions; feel free to disagree)

1) either the dll should not be stripped, or you should distribute an
import lib libbz2.dll.a (I prefer *both* an unstripped dll *and* an
import lib). I don't think it's possible to link directly to a stripped
dll, so providing a stripped dll w/o import lib is not very useful.

2) the dll should not be versioned -- that is, libbz2.dll not
libbz2.1.0.dll. Versioning the dll removes a lot of the benefits dll's
provide. Since the dll must be loaded by windows, we can't play symlink
games like Unix does to get around versioning problems. The actual name
of the dll is encoded into any linked binary -- so if the dll is
versioned, you can't update the dll and automatically update all
binaries that use it. You might as well statically link everything.

I'm thinking here of *other* packages/programs that might link to
libbz2.dll, not the statically linked bzip2.exe provided in =this=
package.

3) the src archive should extract to <cwd>/bzip2-1.0.1 not
<cwd>/src/bzip2-1.0.1

Finally, I'm requesting general comments on this one (well, general
comments on the 3 above is okay too!)

There's no declspec(dllimport) / declspec(dllexport) anywhere, when
building the dll. This is okay -- that is, it should work when using
cygwin tools, because of DJ's work and the fact that there are no DATA
items, only functions in the dll -- but is it the correct thing to do?
Or should the appropriate declspec() definitions be added?

--Chuck