[Zlib-devel] Fwd: zlib 1.2.4 linker with gz functions

[William A. Rowe Jr.]

On 4/18/2010 1:53 PM, Vincent Torri wrote:
> 
> 
> On Sun, 18 Apr 2010, William A. Rowe Jr. wrote:
> 
>> On 4/18/2010 12:04 PM, John Bowler wrote:
>>> From: "Devadatta, Shubha" <Shubha.Devadatta at wardrop.com>
>>>> I just downloaded the zlib version 1.2.4. I use the ÿÿ gzÿÿ functions
>>>> to avoid allocating RAM. However  I am not able to link with the new
>>>> zlib.lib.. I have linker errors  for unresolved symbols for ÿÿgzopenÿÿ
>>>> gzread and gzclose.. gzwrite seems to be resolving w/o any problem..
>>>
>>> I built 1.2.4 on MSYS/MinGW with -f win32/makefile.gcc; make test is
>>> fine.  I copied the official 'zlib.lib' to libz.a, deleted
>>> example.exe and repeated the 'make -f win32/makefile.gcc test', apart
>>> from some warnings about 'unrecognized .drectve' it worked fine (and
>>> it says it calls 'gzread()').
>>>
>>> I repeated with ./configure --static (because the win32 makefile
>>> doesn't set _LARGEFILE64_SOURCE, and this must have something to do
>>> with the problem).  Everything links fine - so I can't reproduce the
>>> gzopen problem - but example64.exe does fail with 'gzread err:'.
>>>
>>> Since win32/makefile.gcc doesn't build example64.exe I don't know if
>>> this is something to do with the configure build.  What does seem
>>> certain is that it is related to the '64' functions, because gzopen,
>>> gzread and gzclose all exist in '64' versions but gzwrite does not.
>>
>> Uh oh - I suspect those still use the wrong object code for the stack,
>> treating
>> z_off64_t as long.  No?
> 
> i don't know if it is related, but, on Win64, long is of size 32 bits
> and not 64 bits

My point exactly.  Once these resolve to a 'true' z_off64_t, and the stack bears
no resemblance to the original, what will happen to compiled consumer code?