Description of problem: Fedora's zlib*.dll's name doesn't match MinGW's zlib*.dll: c.f. http://sourceforge.net/projects/mingw/files/MinGW/zlib/zlib-1.2.3-1-mingw32/libz-1.2.3-1-mingw32-dll-1.tar.gz/download # tar tzf /tmp/libz-1.2.3-1-mingw32-dll-1.tar.gz bin/ bin/libz-1.dll Fedora's ships zlib1.dll: # rpm -ql mingw32-zlib /usr/i686-pc-mingw32/sys-root/mingw/bin/zlib1.dll /usr/i686-pc-mingw32/sys-root/mingw/include/zconf.h /usr/i686-pc-mingw32/sys-root/mingw/include/zlib.h /usr/i686-pc-mingw32/sys-root/mingw/lib/libz.dll.a /usr/i686-pc-mingw32/sys-root/mingw/lib/libz.la Version-Release number of selected component (if applicable): mingw32-zlib-1.2.3-19.fc12.noarch Actual results: *.dll name mismatch. Expected results: Fedora's mingw cross-toolchain packages' *.dll's names to match the native ones. Additional info: * A mingw user informed me that mingw-packages, I am building with Fedora's mingw32-toolchains do not work for him, because of this zlib*dll name mismatch. * I noticed that it's Fedora's *.spec which explictly changes zlib-1.dll into zlib.dll. I do not understand this change.
(In reply to comment #0) > * I noticed that it's Fedora's *.spec which explictly changes zlib-1.dll into > zlib.dll. I do not understand this change. The Fedora spec file[1] does not explicitly rename the DLL. It fixes a bug in the *.la file where the *.la file contains a reference to the wrongly named DLL. Anyway, the upstream (ie. zlib) DLL seems to be called zlib1.dll, and we wouldn't normally change DLL names from upstream. BTW, mixing DLLs built from separate sources is a really bad idea, especially for C++ where it's unlikely to work at all. The only DLLs we work with are the base Windows-supplied DLLs and the ones we built ourselves. [1] http://pkgs.fedoraproject.org/gitweb/?p=mingw32-zlib.git;a=blob;f=mingw32-zlib.spec;hb=HEAD
(In reply to comment #1) > (In reply to comment #0) > BTW, mixing DLLs built from separate sources is a really bad idea, I am not mixing. I am building mingw32 packages with Fedora's mingw32 toolchains, now mingw32 users are complaining these applications fail because they can't find libz1.dll on mingw32. > especially for C++ where it's unlikely to work at all. The only DLLs > we work with are the base Windows-supplied DLLs and the ones > we built ourselves. Well, a cross-toolchain's purpose is to enable users to build packages for the target, here mingw32. I.e. the cross-toolchain must match the native plattform (here: www.mingw.org)
The "Fedora MinGW" project is a little misnamed. We're really just a Fedora Windows gcc cross-compiler and we use a bit of runtime from mingw.org (although later on we intend to replace as much as possible with code from the separate mingw-w64 project). The fact that mingw.org also builds some libraries isn't really anything to do with this project. You really won't find that mingw.org libraries they happen to build are compatible with our cross-compiled libraries (although the most acute incompatibilities are with C++ programs). Ship our zlib1.dll to be on the safe side.
(In reply to comment #3) > The "Fedora MinGW" project is a little misnamed. We're really just a Fedora > Windows gcc cross-compiler and we use a bit of runtime from mingw.org > (although later on we intend to replace as much as possible with code from > the separate mingw-w64 project). The fact that mingw.org also builds > some libraries isn't really anything to do with this project. Hmm, to me this is a pretty bewildering excuse, because a cross toolchain which doesn't match the native host's libraries it targets, is widely free of sense and useless. > You really won't find that mingw.org libraries they happen to build are > compatible with our cross-compiled libraries (although the most acute > incompatibilities are with C++ programs). Ship our zlib1.dll to be > on the safe side. Well, then you likely may want to launch a native mingw32 distro, matching your ming32 packages, such that your ming32 toolchain finally has a target platform or help mingw32.org? However, I'd seriously recommend you fix your toolchain to match with that toolchain packages windoze users are really using (mingw.org). I regret, but in it's present shape your cross-toolchain is more a waste of diskspace but real support for cross-building to Windows.
(In reply to comment #4) > (In reply to comment #3) > > The "Fedora MinGW" project is a little misnamed. We're really just a Fedora > > Windows gcc cross-compiler and we use a bit of runtime from mingw.org > > (although later on we intend to replace as much as possible with code from > > the separate mingw-w64 project). The fact that mingw.org also builds > > some libraries isn't really anything to do with this project. > Hmm, to me this is a pretty bewildering excuse, because a cross toolchain which > doesn't match the native host's libraries it targets, is widely free of sense > and useless. Not quite sure what you mean by this. _I_ meant that we target Microsoft Windows which has some DLLs that we support (eg. user32.dll). zlib is not AFAIK a part of Microsoft Windows: I checked and it is not included in Windows 7. Microsoft ship a library called lz32.dll which is their native compression library (it could be based on the zlib code, I'm not sure). > > You really won't find that mingw.org libraries they happen to build are > > compatible with our cross-compiled libraries (although the most acute > > incompatibilities are with C++ programs). Ship our zlib1.dll to be > > on the safe side. > > Well, then you likely may want to launch a native mingw32 distro, matching your > ming32 packages, such that your ming32 toolchain finally has a target platform > or help mingw32.org? That's never been a part of any plan that I'm aware of. This project has always been about cross-compiling binaries so that they can run on Microsoft Windows. > However, I'd seriously recommend you fix your toolchain to match with that > toolchain packages windoze users are really using (mingw.org). > I regret, but in it's present shape your cross-toolchain is more a waste of > diskspace but real support for cross-building to Windows. We don't expect that users have installed mingw.org. We want to ship binaries which can run completely independently of this, just on plain MS Windows. This has always been the goal of the project.
(In reply to comment #5) > > That's never been a part of any plan that I'm aware of. This project > has always been about cross-compiling binaries so that they can run > on Microsoft Windows. If this is the case the results of this process are in error because users do not have the required libraries available to them. Software built with this package reference DLLs that are not part of a standard Windows installation nor MinGW. The effect of this is to create a new list of dlls needed to support any executable built with this package. > > However, I'd seriously recommend you fix your toolchain to match with that > > toolchain packages windoze users are really using (mingw.org). > > I regret, but in it's present shape your cross-toolchain is more a waste of > > diskspace but real support for cross-building to Windows. > > We don't expect that users have installed mingw.org. We > want to ship binaries which can run completely independently > of this, just on plain MS Windows. This has always been the > goal of the project. That is not the current state of what is happening. I seems to me you either need to remove all dependencies and reference just what is in a base Windows installation, reference a project that can provide those referenced DLLs, eg MinGW, or create a means of distributing those DLLs you reference.
(In reply to comment #6) > If this is the case the results of this process are in error because users do > not have the required libraries available to them. Yes they do. Use mingw32-nsiswrapper which generates the list of DLLs and packages the ones that we provide. I'm closing this bug as NOTABUG. It's not useful to have these sorts of discussions in bugzilla comments. Please use the mailing list.