Menu
▾
▴
[Tcl-bugs] [ tcl-Feature Requests-2605263 ] use official win32 zlib build.
|
From: SourceForge.net <no...@so...> - 2009-07-08 08:14:38
|
Feature Requests item #2605263, was opened at 2009-02-16 12:46 Message generated for change (Comment added) made by nijtmans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360894&aid=2605263&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 57. zlib Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Jan Nijtmans (nijtmans) Assigned to: Jan Nijtmans (nijtmans) Summary: use official win32 zlib build. Initial Comment: Currently, on UNIX, the configure script checks if the system has a suitable built-in zlib library. If so, the external library is used, otherwise the one from compat. On win32, there is an official zlib build that has two advantages compared to the current situation: - The basic compression functions come from hand-optimized assembler code, so it is faster. - The library has the form of a dll, so when a better zlib version comes out, it's just a matter of replacing this dll with a newer one and everything will still work. This should only be used for win32 (not for win64) and only with --enable-shared: For starpacks we don't want to depend on an external zlib1.dll, which is not guaranteed to be installed. Rule: only depend on zlib1.dll when we depend on tcl86.dll already. There is a disadvantage as well: The official build is missing two functions which (by accident) are not exported from the dll although they are part of the official API. There exists a hack for that. ---------------------------------------------------------------------- >Comment By: Jan Nijtmans (nijtmans) Date: 2009-07-08 10:14 Message: Already in the build, so can be closed now ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2009-02-17 12:10 Message: On Windows, zlib1.dll is never present on the system. It comes with the applications that need it. As soon as there exists an official zlib1.dll which doesn't need the hack any more, you are right that your suggestion would be better. At this moment I see more risks in doing that than that it benefits. It can always be added in the future. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-02-17 10:47 Message: You need to ensure that you use configure.in to detect whether a zlib1.dll is present and has all the functions required. I advise adapting what the Unix configure.in does; that already spots the function that tends to be the issue when it comes to versioning... ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2009-02-17 00:07 Message: Fixed for win/Makefile, win/makefile.vc still to be done. Tested with both msvc and mingw32. For related install scripts (Activetcl ???), this change means that zlib1.dll must be installed side by side with tcl86.dll as a companion. For tkImg, I am planning to make the same change, so zlib1.dll will be used by both tcl and tkImg. And there are a lot other applications which distribute the same zlib1.dll. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2009-02-16 14:40 Message: Yes, agreed. However, in this case the 'hack' only consists of copying the missing functions (of only a few lines each) in tclZlib.c. So, the 'hack' is 'easy enough' as well. Given the fact that the official zlib build is faster then ours, I am inclined to fix this (I already have tested the fix locally, so I am confident enough about it!). However, I encourage anyone to give more arguments pro or contra. Thanks, Donal! ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2009-02-16 14:33 Message: If we're having to hack around faults in the official build, that negates the benefits of using it since we can build our own easily enough. Since the official build is broken, we can close this bug as a "won't fix" until that is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360894&aid=2605263&group_id=10894 |