OpenNURBS and ZLIB?

darbyjohnston · November 29, 2019, 7:12pm

Hi,

I’m trying to incorporate OpenNURBS into my project and am running into some linking errors with ZLIB:

14>zlibd.lib(inflate.obj) : error LNK2005: inflatePrime already defined in opennurbs.lib(inflate.obj)
14>zlibd.lib(inflate.obj) : error LNK2005: inflateGetHeader already defined in opennurbs.lib(inflate.obj)
14>zlibd.lib(adler32.obj) : error LNK2005: adler32_combine already defined in opennurbs.lib(adler32.obj)
14>zlibd.lib(crc32.obj) : error LNK2005: crc32_combine already defined in opennurbs.lib(crc32.obj)
14>zlibd.lib(deflate.obj) : error LNK2005: deflate_copyright already defined in opennurbs.lib(deflate.obj)
14>zlibd.lib(deflate.obj) : error LNK2005: deflateTune already defined in opennurbs.lib(deflate.obj)
14>zlibd.lib(deflate.obj) : error LNK2005: deflateSetHeader already defined in opennurbs.lib(deflate.obj)
14>zlibd.lib(trees.obj) : error LNK2005: _length_code already defined in opennurbs.lib(trees.obj)
14>zlibd.lib(trees.obj) : error LNK2005: _dist_code already defined in opennurbs.lib(trees.obj)
14>zlibd.lib(trees.obj) : error LNK2005: _tr_init already defined in opennurbs.lib(trees.obj)
14>zlibd.lib(trees.obj) : error LNK2005: _tr_tally already defined in opennurbs.lib(trees.obj)
14>zlibd.lib(trees.obj) : error LNK2005: _tr_flush_block already defined in opennurbs.lib(trees.obj)
14>zlibd.lib(trees.obj) : error LNK2005: _tr_align already defined in opennurbs.lib(trees.obj)
14>zlibd.lib(trees.obj) : error LNK2005: _tr_stored_block already defined in opennurbs.lib(trees.obj)

It looks like not all of the ZLIB symbols are using the “Z_PREFIX” decoration and are colliding with another version of ZLIB I am linking with. It looks like the latest version of ZLIB may fix this, there are considerably more Z_PREFIX defines in the latest zconf.h file:

github.com

madler/zlib/blob/master/zconf.h

/* zconf.h -- configuration of the zlib compression library
 * Copyright (C) 1995-2016 Jean-loup Gailly, Mark Adler
 * For conditions of distribution and use, see copyright notice in zlib.h
 */

/* @(#) $Id$ */

#ifndef ZCONF_H
#define ZCONF_H

/*
 * If you *really* need a unique prefix for all types and library functions,
 * compile with -DZ_PREFIX. The "standard" zlib should be compiled without it.
 * Even better than compiling with -DZ_PREFIX would be to use configure to set
 * this permanently in zconf.h using "./configure --zprefix".
 */
#ifdef Z_PREFIX     /* may be set to #if 1 by ./configure */
#  define Z_PREFIX_SET

/* all linked symbols and init macros */

This file has been truncated. show original

Would upgrading the ZLIB code in OpenNURBS be a possibility?

Thanks, Darby

PS. I’m using the latest OpenNRUBS code from: https://github.com/mcneel/opennurbs.git

dale · December 1, 2019, 4:13am

Hi @darbyjohnston,

No, there is no reason to update zlib.

Are you using Visual Studio? What version? Are you linking the static or dynamic library? Did you look at the samples included in the repo?

Any additional details you can provide might be helpful.

– Dale

darbyjohnston · December 1, 2019, 8:22pm

Hi Dale,

Thanks for the reply; I’m trying to link opennurbs to my application as a static library built using a simple CMake file I wrote. The issue is that my application also links to other libraries that use zlib and that’s causing link errors with the version embedded in opennurbs. This shouldn’t happen because opennurbs specifically defines Z_PREFIX to prevent this (https://github.com/mcneel/opennurbs/blob/7.x/zlib/zconf.h#L40), but it looks like not all of the symbols are actually protected.

The latest version of zlib (v1.2.11) has fixes for most of the missing Z_PREFIX decorations which is why I was asking about the possibility of upgrading. As a test I forked opennurbs and replaced the zlib files:

There was still one symbol missing a Z_PREFIX decoration but after fixing that I can now successfully link to opennurbs.

This is with Visual Studio 2019 on Windows 10.

Thanks, Darby

dale · December 18, 2019, 12:27am

Hi @darbyjohnston,

If static linking is required, then it might be possible to use a namespace for the zlib that ships with openNURBS and tweak the openNURBS code accordingly. This type of issue is one that dynamic linking openNURBS solves.

The other option is to use a single zlib and update source as needed to resolve issues. We have no plans to change the version of zlib openNURBS uses and no plans to change the way openNURBS is statically linked.

– Dale

darbyjohnston · December 19, 2019, 10:27pm

Hi Dale,

Thanks, I was trying to avoid dynamic linking so I might try the namespace.

I’m not an expert on linking but it seems like there would still be issues with dynamic linking to another zlib library if not all of the zlib symbols inside OpenNURBS are actually protected with Z_PREFIX?

Darby