[Zlib-devel] Fwd: zlib 1.2.4 linker with gz functions
William A. Rowe Jr.
wrowe at rowe-clan.net
Mon Apr 19 13:19:57 EDT 2010
On 4/19/2010 12:10 PM, Mark Adler wrote:
> Some more data on zlib Windows linking issues.
>
> Mark
>
>
> Begin forwarded message:
>> From: "Devadatta, Shubha" <Shubha.Devadatta at wardrop.com>
>> Date: April 19, 2010 9:34:29 AM PDT
>> To: Mark Adler <madler at alumni.caltech.edu>
>> Cc: "jloup at gzip.org" <jloup at gzip.org>
>> Subject: RE: zlib 1.2.4 linker with gz functions
>>
>> Hi Mark, appreciate your response..
>> I use windows XP, running Visual studio 6 compiler.
>>
>> Previous version used was 1.2.1..
>> - removed previous zlib directory to which the paths for include/linking etc were set.
>> - brought in new zlib124, set path to zlib124 in the vc++ project options.
>>
>> - copied the zlib1.dll renamed to zlib.dll in the linker path. Made the ZLIB_DLL macro setting in the options
Renaming is no good, it sounds like the user is creating themselves a mess. They
want to link to zdll.lib, and that library contains a hardcoded zlib1.dll reference.
The ZLIB_DLL macro must not be used. They need to remove that definition from
their code project, recompile and attempt to relink all of their consuming code.
It's all been this way since 1.2.3, and since 1.2.1 has been loudly proclaimed to
have security issues for some time, it seems overdue for this user to make an
investment in getting their build set up correctly. I rather expect they are
trying to move from 1.1 to 1.2 and that's the origin of their headaches.
>> - Build..
>>
>> Gives the following errors.
>>
>> error LNK2001: unresolved external symbol __imp__gzclose at 4
>> CDRFileCracker.obj : error LNK2001: unresolved external symbol __imp__gzread at 12
>> CDRFileCracker.obj : error LNK2001: unresolved external symbol __imp__gzopen at 8
More information about the Zlib-devel
mailing list