New version of bzip2 uploaded to sourceware

[Charles Wilson]

Michael Ring wrote:
> 
> 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.
> 

But you have to remember to update libcygwin.a, not just cygwin1.dll

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

There are two advantages. The importance of each is a matter of opinion;
feel free to disagree and do it whatever way makes sense to you.

1) reporting bugs to the maintainer. I *think* foo.exe.stackdump is a
bit more informative if the dependent dll's are unstripped, but I could
be wrong. 

2) flexibility. The end user can *either* link to the implib *or*
directly to the dll. Whatever =they= want, not what =we= decide.

Are these worth the massive increase in download size? I dunno. Each
maintainer needs to make that call for their packages.

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

This works only if you provide an import lib. ld will not find
libbz2.1.0.dll if the dependent project's Makefile says 'gcc -o foo.exe
-lbz2' ld.exe *will* find libbz2.dll.

The same thing is true in unix, but unix can play symlink games because
both the linker and the runtime-dynamic-loader understand symlinks.
Windows doesn't.

Here's an example:

libz.dll -> libz.1.1.dll
rm libz.dll.a
ld.exe -Bdynamic -o minigzip.exe /usr/lib/crt0.o -L.
-L./usr/lib/gcc-lib/i686-pc-cygwin/2.95.2
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib
minigzip.pic.o -lz -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32
-lshell32 -lgcc --verbose

...
attempt to open ./libz.dll.a failed
attempt to open ./z.dll.a failed
attempt to open ./libz.dll succeeded (remember, libz.dll is a symlink

cygcheck minigzip.exe
Found: .\minigzip.exe
.\minigzip.exe
  D:\cygwin\bin\cygwin1.dll
    D:\WINNT\System32\KERNEL32.dll
      D:\WINNT\System32\NTDLL.DLL
  .\libz.dll

Notice that the name of the SYMLINK is embedded in the dll, not the
actual name of the dll itself. Thus, since windows, the
runtime-dynamic-loader, doesn't grok symlinks, it won't be able to find
libz.1.1.dll.

So, we can't play symlink games on cygwin/windows.


What does this mean? EVERY dependent package MUST edit it's Makefile and
use '-lz.1.1' instead of '-lz' if you want to link directly to the dll.
Now, you can get around this by supplying an import lib called
'libz.dll.a' that *knows* that the dll is called 'libz.1.1.dll':

gcc -shared -Wl,--out-implib=libz.dll.a -o libz.1.1.dll

will do it, and everything will work. However, it forces users to use
the import lib; they can never link directly to the dll unless they
munge their own makefile.


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

IIRC, -soname means nothing on cygwin. The linker looks at the filename
of the shared library only. I think.

> (Aehm which reminds
> me, at this time the versioninfo fields inside of the dll are not
> filled. My bug or an unimplemented feature ??)

I think you need to use a VERSIONINFO field in the .def file, but this
feature may not be implemented yet.

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

Linux Standard Project says that the major version is the only thing
that changes when backwards-incompatible changes are added. Minor
version changes when the so is still compatible with older applications,
but newer apps can take advantage of new features in the so. The micro
version changes for bugfix. Right?

So, libbz2.1.1.dll should be usable by programs compiled for
libbz2.1.0.dll; with your naming scheme and the oddities of windows,
that will not be true.

So, if you must version, then use libbz2.1.dll. The only drawback,
assuming the true maintainer of the global bzip package follows the
requirements of the LSP, is that new programs built for 1.1.x library
will not link with a 1.0.x library, but both libraries would be called
libbz2.1.dll. However, that shows up at link time, not runtime. Link
errors are better than avoidable runtime errors; the 1.1.x library
should really work with older programs compiled for the 1.0.x library,
according to LSP.

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


Perhaps the stuff in 'latest' must be <cwd>/src/.... but the things in
'contrib' are allowed to be <cwd>/... ?

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

To boil it all down, unless you rewrite the windows dynamic loader code,
versioned libraries just ain't supported well. So yeah, nonversioned
causes problems; welcome to windows. Versioned libraries *on windows
when using unix-y makefiles* are even worse. I think this is one of the
windows-isms that is counterproductive (i.e. FAQ-generating) to try to
fix.

--Chuck