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
From: michael-ring AT t-online DOT de (Michael Ring)
To: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
Cc: cygwin-apps AT sources DOT redhat DOT com
Subject: Re: New version of bzip2 uploaded to sourceware
Date: Wed, 12 Jul 2000 19:33:03 +0200
Message-ID: <0c9pmsk6uu4nv1q74i1a3hdn28uprug72n@4ax.com>
References: <9jlomsk2sk0qp6hkumfpovn69lipbi251e AT 4ax DOT com> <396CA424 DOT CA1719EB AT ece DOT gatech DOT edu>
In-Reply-To: <396CA424.CA1719EB@ece.gatech.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit

On Wed, 12 Jul 2000 13:00:20 -0400, you wrote:

>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.
>

I am using CYGWIN_NT-5.0 BOWMAN 1.1.3s(0.24/3/2) 2000-07-10 23:55 i686
unknown.

I read that the bug was completely fixed on 11th, perhaps the snapshot
from 10th already fixed some of the trouble. I will look if I can find
a newer one and have a look at it.

>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.

O.K. Providing an import lib seems to make sense. 8-)
Of course I did not find the problem because compile of dll and the
.exe happen directly one after another. Thanks for pointing that out.

Where is the advantage of also providing an unstripped dll? If someone
needs to debug deep into the lib he should re-compile it for him/her
self. Size does not matter in this particular dll but if I think about
gtk or gnome libs that's another story.

>
>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. 

Some of the ugliest problems with Microsoft apps are based on the lack
of versioning. I still can remember the trouble ctrl3d.dll caused a
few years ago. I think we should stick with the default naming for
dll's that was intended by the autor of the particular software that
was ported. In the case of bzip2 the autor wanted the soname to be set
to 1.0. (In his case libbz2.so.1.0)

If the author of a software changes the versioning and the soname,
this normally means the software is not interface-compatible anymore.
In this case we would be save, it is possible to provide the new dll
and the convert applications to the new lib. But older apps will still
run because the dll for the old apps is versioned.

>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.
>

There's no need to play symlink games if we reference to the soname.
symlinks are only a way to show the real version under unix. But this
is done inside the dll in the version information (Aehm which reminds
me, at this time the versioninfo fields inside of the dll are not
filled. My bug or an unimplemented feature ??)
static linking would be to provide a dll named libbz2.1.0.1.dll. But
this one is named libbz2.1.0.dll which leaves a lot of space for
interface-compatible changes.

>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
>

Yow, count me on the list of supporters for this! I did include the
src directory because this seems the way that src-packages are done at
this time. I also do not like this and only did it like the 'rest of
the herd. 

>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?
>

Sorry, out of my scope. Ask corinna about my compiler-language
preferences ;-)


Michael