From: Vincent T. <vt...@un...> - 2007-04-29 22:30:52
|
Hey, I just tried to use the MinGW ports avaiable on SF. I followed the documentation on the wiki. Hence, the libjpeg port was successfully compiled and installed. I tried the zlib port, but an error occured: ar rcs libz.a adler32.o compress.o crc32.o deflate.o gzio.o infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zutil.o windres --define GCC_WINDRES -o zlibrc.o win32/zlib1.rc dllwrap --driver-name gcc --def win32/zlib.def \ --implib libz.dll.a -o zlib1.dll adler32.o compress.o crc32.o deflate.o gzio.o infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zutil.o zlibrc.o D:\msys\1.0\mingw\bin\dllwrap.exe: CreateProcess: No error make: *** [zlib1.dll] Error 1 Is there a missing package that I have to install in order to get that zlib port ? thank you Vincent Torri |
From: Keith M. <kei...@to...> - 2007-05-01 10:48:26
|
Vincent Torri wrote: > I tried the zlib port, but an error occured: I assume you mean this: http://downloads.sourceforge.net/mingw/zlib-1.2.3-mingwPORT-1.tar.bz2 and that you will be building from: http://www.zlib.net/zlib-1.2.3.tar.bz2 That port has been built with an older (broken) version of portmaker, which causes it to try to cd /usr/src/zlib-1.2.3/.. *before* the /usr/src/zlib-1.2.3 parent has been created. This `cd' command fails, resulting in failure of the port. To work around this you must mkdir -p /usr/src/zlib-1.2.3 *before* you run `mingwPORT.sh'. Assuming that you've done that, then this port should build ok. I've just run it, as above, and I cannot reproduce this: > ar rcs libz.a adler32.o compress.o crc32.o deflate.o gzio.o \ > infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o \ > zutil.o > windres --define GCC_WINDRES -o zlibrc.o win32/zlib1.rc > dllwrap --driver-name gcc --def win32/zlib.def \ > --implib libz.dll.a -o zlib1.dll adler32.o compress.o crc32.o \ > deflate.o gzio.o infback.o inffast.o inflate.o inftrees.o \ > trees.o uncompr.o zutil.o zlibrc.o > D:\msys\1.0\mingw\bin\dllwrap.exe: CreateProcess: No error > make: *** [zlib1.dll] Error 1 Even when I didn't create the parent source directory first, I don't see this symptom; it fails long before it gets this far. When I do create the directory first, it all builds cleanly for me. It is curious that dllwrap says `CreateProcess: No error', and then proceeds to terminate abnormally; seems to point to a possible bug in dllwrap, bug it's going to be well nigh impossible to track it down, if we can't reliably reproduce it. > Is there a missing package that I have to install in order to get > that zlib port ? Can't think of anything, beyond a full MinGW install, and MSYS; you might also like to install the msysDTK, but I don't think that it is really necessary -- your failure appears to be associated with a tool which is provided by the MinGW install. Sorry, can't be more helpful. Regards, Keith. |
From: Vincent T. <vt...@un...> - 2007-05-01 10:55:45
|
On Tue, 1 May 2007, Keith MARSHALL wrote: > Vincent Torri wrote: >> I tried the zlib port, but an error occured: > > I assume you mean this: > http://downloads.sourceforge.net/mingw/zlib-1.2.3-mingwPORT-1.tar.bz2 yes > and that you will be building from: > http://www.zlib.net/zlib-1.2.3.tar.bz2 yes >> ar rcs libz.a adler32.o compress.o crc32.o deflate.o gzio.o \ >> infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o \ >> zutil.o >> windres --define GCC_WINDRES -o zlibrc.o win32/zlib1.rc >> dllwrap --driver-name gcc --def win32/zlib.def \ >> --implib libz.dll.a -o zlib1.dll adler32.o compress.o crc32.o \ >> deflate.o gzio.o infback.o inffast.o inflate.o inftrees.o \ >> trees.o uncompr.o zutil.o zlibrc.o >> D:\msys\1.0\mingw\bin\dllwrap.exe: CreateProcess: No error >> make: *** [zlib1.dll] Error 1 > > It is curious that dllwrap says `CreateProcess: No error', and then > proceeds to terminate abnormally; seems to point to a possible bug > in dllwrap, bug it's going to be well nigh impossible to track it > down, if we can't reliably reproduce it. where can I download the latest dllwrap file ? (maybe I have a wrong version. I installed mingw 5.1.3) Vincent Torri |
From: Keith M. <kei...@to...> - 2007-05-01 11:33:25
|
Vincent Torri wrote: > where can I download the latest dllwrap file ? (maybe I have a > wrong version. I installed mingw 5.1.3) What version do you have? Mine is $ dllwrap --version GNU d:\usr\mingw\bin\dllwrap.exe 2.17.50 20060824 Did you install `Candidate' or `Current'? `Candidate' will give you the latest version, (which is 2.17.50, as above). `Current' may give you an earlier version, (2.16.91 IIRC). Regards, Keith. |
From: Vincent T. <vt...@un...> - 2007-05-01 10:59:21
|
On Tue, 1 May 2007, Keith MARSHALL wrote: > It is curious that dllwrap says `CreateProcess: No error', and then > proceeds to terminate abnormally; seems to point to a possible bug > in dllwrap, bug it's going to be well nigh impossible to track it > down, if we can't reliably reproduce it. as the wiki says: "dllwrap is a tool to build DLLs. It seems to be deprecated in favour of gcc -shared option". As zlib is already patched, maybe one should modify the makefile so that gcc is used to create the shared lib. Vincent |
From: Keith M. <kei...@to...> - 2007-05-01 11:27:04
|
Vincent Torri wrote, quoting me: >> It is curious that dllwrap says `CreateProcess: No error', and then >> proceeds to terminate abnormally; seems to point to a possible bug >> in dllwrap, bug it's going to be well nigh impossible to track it >> down, if we can't reliably reproduce it. > > as the wiki says: "dllwrap is a tool to build DLLs. It seems to be > deprecated in favour of gcc -shared option". As zlib is already > patched, maybe one should modify the makefile so that gcc is used > to create the shared lib. Ideally, that makes sense. Patches please, and please report this upstream to zlib maintainers, so they can address it appropriately. Regards, Keith. |
From: Vincent T. <vt...@un...> - 2007-05-01 12:11:43
Attachments:
mingwPORT.patch
|
On Tue, 1 May 2007, Keith MARSHALL wrote: > Vincent Torri wrote, quoting me: >> as the wiki says: "dllwrap is a tool to build DLLs. It seems to be >> deprecated in favour of gcc -shared option". As zlib is already >> patched, maybe one should modify the makefile so that gcc is used >> to create the shared lib. > > Ideally, that makes sense. Patches please, and please report this > upstream to zlib maintainers, so they can address it appropriately. I have attached a new patch for the zlib port. It uses gcc to create the shared library. I also changed the name zlib1.dll to a more classic name : libz-1.dll It seems to work for me. I'm waiting mailman to accept my subscription the the zlib ML... It would be great if they apply the mingw patch entirely, btw. regards Vincent Torri |
From: Charles W. <cwi...@us...> - 2007-05-01 14:36:02
Attachments:
zlib-1.2.3-2.src.patch
|
Vincent Torri wrote: > I have attached a new patch for the zlib port. It uses gcc to create the > shared library. > > I also changed the name zlib1.dll to a more classic name : libz-1.dll This is good -- and bad. According to http://www.zlib.net/DLL_FAQ.txt the name 'zlib1.dll' is reserved explicitly for a zlib DLL compiled in a specific manner, guaranteeing compatibility for win32 users who just want to download the DLL itself. Otherwise, system integrators are asked to use a name other than 'zlib1.dll'. However, I believe that mingw's zlib dll *is* compiled in the correct manner, and should be interface-compatible with the official zlib dll. So, we *could* use the 'zlib1.dll' name if we choose to. > > It seems to work for me. > > I'm waiting mailman to accept my subscription the the zlib ML... It > would be great if they apply the mingw patch entirely, btw. But the above comments are one reason why not all of your changes will be accepted: they WANT to name the official win32 dll 'zlib1.dll' -- and I think "official" means "built using the unmodified win32 gcc makefile". Ditto for INCLUDE_PATH and LIBRARY_PATH (which they expect to be defined in the environment, just like MSVC, without reliance on some "prefix".) My suggestion: use the patch from cygwin (attached) which modifies the top-level Makefile.in and configure. (This patch already includes some mingw-specific changes). Then, do a regular 'configure && make' instead of 'make -f win32/Makefile.gcc' You will probably need to modify some parts of the patch, as the mingw bits have likely bitrotted. Also, the patch defines the dll name as "mgwz.dll" based on an old (rejected) idea of mine; you'll want to change that. -- Chuck |
From: Vincent T. <vt...@un...> - 2007-05-02 21:55:52
|
On Tue, 1 May 2007, Charles Wilson wrote: > Vincent Torri wrote: >> I have attached a new patch for the zlib port. It uses gcc to create the >> shared library. >> >> I also changed the name zlib1.dll to a more classic name : libz-1.dll > > This is good -- and bad. According to http://www.zlib.net/DLL_FAQ.txt the > name 'zlib1.dll' is reserved explicitly for a zlib DLL compiled in a specific > manner, guaranteeing compatibility for win32 users who just want to download > the DLL itself. Otherwise, system integrators are asked to use a name other > than 'zlib1.dll'. > > However, I believe that mingw's zlib dll *is* compiled in the correct manner, > and should be interface-compatible with the official zlib dll. So, we *could* > use the 'zlib1.dll' name if we choose to. ok. I can make the patch without changing the lib name. Keith, would it be good for you ? > > My suggestion: use the patch from cygwin (attached) which modifies the > top-level Makefile.in and configure. (This patch already includes some > mingw-specific changes). Then, do a regular 'configure && make' instead of > 'make -f win32/Makefile.gcc' > > You will probably need to modify some parts of the patch, as the mingw bits > have likely bitrotted. Also, the patch defines the dll name as "mgwz.dll" > based on an old (rejected) idea of mine; you'll want to change that. maybe I'll look at it. I don't know if using autofoo is really useful here, as you just compile few files and just create the library from them. Vincent Torri |
From: Keith M. <kei...@to...> - 2007-05-03 11:53:11
|
Vincent Torri wrote, quoting Charles Wilson: >>> I also changed the name zlib1.dll to a more classic name : libz-1.dll >> >> This is good -- and bad. According to http://www.zlib.net/DLL_FAQ.txt the >> name 'zlib1.dll' is reserved explicitly for a zlib DLL compiled in a specific >> manner, guaranteeing compatibility for win32 users who just want to download >> the DLL itself. Otherwise, system integrators are asked to use a name other >> than 'zlib1.dll'. >> >> However, I believe that mingw's zlib dll *is* compiled in the correct manner, >> and should be interface-compatible with the official zlib dll. So, we *could* >> use the 'zlib1.dll' name if we choose to. > > ok. I can make the patch without changing the lib name. Keith, would it be > good for you ? If it is *guaranteed* 100% ABI compatible with the official binary download from zlib.net, then I don't see any problem; have you tried running their test suite, from the official build package, to confirm this? Do we really gain anything by building this ourselves, rather than just grabbing the official build from any of: http://www.zlib.net/zlib123-dll.zip http://www.gzip.org/zlib/zlib123-dll.zip, or http://prdownloads.sourceforge.net/libpng/zlib123-dll.zip?download If not, what's the rationale for offering this as a mingwPORT? Regards, Keith. |
From: Vincent T. <vt...@un...> - 2007-05-03 12:04:58
|
> If it is *guaranteed* 100% ABI compatible with the official binary > download > from zlib.net, then I don't see any problem; have you tried running their > test suite, from the official build package, to confirm this? i've not run them. I'll do it this evening > Do we really gain anything by building this ourselves, rather than just > grabbing the official build from any of: > http://www.zlib.net/zlib123-dll.zip > http://www.gzip.org/zlib/zlib123-dll.zip, or > http://prdownloads.sourceforge.net/libpng/zlib123-dll.zip?download > > If not, what's the rationale for offering this as a mingwPORT? With this archive, libtool can't create shared lib of a library which uses zlib. That's why I tried the mingw port, btw. Vincent |
From: Tor L. <tm...@ik...> - 2007-05-09 22:29:38
|
Keith MARSHALL writes: > Do we really gain anything by building this ourselves, rather than just > grabbing the official build Exactly my point of view, too. Zlib is a pretty stable library (API-wise). And as it is one of the few commonly used FOSS libraries that actually has an upstream official Windows build, why not just use that binary instead of insisting on proliferating separately built potentially slightly different copies of it. Vincent Torri writes: > With this archive, libtool can't create shared lib of a library which uses > zlib. No need to rebuild the binary to fix that. I have worked around this myself long ago, can't recall the details. Was it enough to just copy the zdll.lib file to libz.a? Or freshly prepare an import library either from the DLL using pexports or whatever, or from the supplied .def file. Probably the upstream zlib people would be more than happy to include an official .a import library, too, if someone just suggested it to them. --tml |
From: Vincent T. <vt...@un...> - 2007-05-10 06:03:27
|
Btw, why does the gnuwin32 binary package does not put zlib1.dll in a bin/ dir, whereas all the other libs (found on gnuwin32) I looked at do ? Vincent On Thu, 10 May 2007, Tor Lillqvist wrote: > Keith MARSHALL writes: > > Do we really gain anything by building this ourselves, rather than just > > grabbing the official build > > Exactly my point of view, too. Zlib is a pretty stable library > (API-wise). And as it is one of the few commonly used FOSS libraries > that actually has an upstream official Windows build, why not just use > that binary instead of insisting on proliferating separately built > potentially slightly different copies of it. > > Vincent Torri writes: > > With this archive, libtool can't create shared lib of a library which uses > > zlib. > > No need to rebuild the binary to fix that. I have worked around this > myself long ago, can't recall the details. Was it enough to just copy > the zdll.lib file to libz.a? Or freshly prepare an import library > either from the DLL using pexports or whatever, or from the supplied > .def file. Probably the upstream zlib people would be more than happy > to include an official .a import library, too, if someone just > suggested it to them. > > --tml > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > > -- > Ce message a été vérifié par MailScanner > pour des virus ou des polluriels et rien de > suspect n'a été trouvé. > Message délivré par le serveur de messagerie de l'Université d'Evry. > > |
From: Keith M. <kei...@to...> - 2007-05-10 09:17:09
|
Vincent Torri wrote: > Btw, why does the gnuwin32 binary package does not put zlib1.dll > in a bin/ dir, whereas all the other libs (found on gnuwin32) I > looked at do ? I've no idea. GnuWin32 is a completely independent project, (maintained by Kees Zeelenberg, IIRC). Only he can answer this; you'd need to ask on the GnuWin32-Help list, or forum. In any case, the canonical source for the officially built zlib1.dll would be via one of the links at http://www.zlib.org, so why do we also need a GnuWin32 port? Doesn't that also fall into the category of needless proliferation? This quote says it all... Tor Lillqvist wrote, quoting me: >> Do we really gain anything by building this ourselves, rather than >> just grabbing the official build > > Exactly my point of view, too. Zlib is a pretty stable library > (API-wise). And as it is one of the few commonly used FOSS libraries > that actually has an upstream official Windows build, why not just > use that binary instead of insisting on proliferating separately > built potentially slightly different copies of it. Regards, Keith. |