Building v5.1.6 gives error: 'zlib_filefunc_def' {aka 'struct zlib_filefunc_def_s'} has no member named 'zopendisk_file'

[brechtsanders]

Building v5.1.6 gives error: 'zlib_filefunc_def' {aka 'struct zlib_filefunc_def_s'} has no member named 'zopendisk_file'.

I'm on Windows 11 using MinGW-w64 GCC 11.2.0 and I have all dependancies installed from latest versions.

Whe building assimp 5.1.6 I get:

R:/winlibs64-11.2.0ucrt/assimp-5.1.6/code/Common/ZipArchiveIOSystem.cpp: In static member function 'static zlib_filefunc_def Assimp::IOSystem2Unzip::get(Assimp::IOSystem*)':
R:/winlibs64-11.2.0ucrt/assimp-5.1.6/code/Common/ZipArchiveIOSystem.cpp:200:13:
error: 'zlib_filefunc_def' {aka 'struct zlib_filefunc_def_s'} has no member named 'zopendisk_file'; did you mean 'zopen_file'?
  200 |     mapping.zopendisk_file = (opendisk_file_func)opendisk;
      |             ^~~~~~~~~~~~~~
      |             zopen_file
R:/winlibs64-11.2.0ucrt/assimp-5.1.6/code/Common/ZipArchiveIOSystem.cpp:200:31:
error: 'opendisk_file_func' was not declared in this scope; did you mean 'open_file_func'?
  200 |     mapping.zopendisk_file = (opendisk_file_func)opendisk;
      |                               ^~~~~~~~~~~~~~~~~~
      |                               open_file_func
ninja: build stopped: subcommand failed.

When checking I noticed there are different ioapi.h versions around with and without zopendisk_file defined as member of zlib_filefunc_def_s. From what I see I think ZOPENDISK64 seems like a good macro to check to determine if zopendisk_file is to be used or not.

So I was able to build assimp 5.1.6 after the following patch:

patch -ulbf code/Common/ZipArchiveIOSystem.cpp << EOF
@@ -198,3 +198,5 @@
     mapping.zopen_file = (open_file_func)open;
+#ifdef ZOPENDISK64
     mapping.zopendisk_file = (opendisk_file_func)opendisk;
+#endif
     mapping.zread_file = (read_file_func)read;
EOF

But I'm not sure if that breaks anything else...

[ryandesign]

I have essentially the same problem trying to build assimp 5.1.6 on macOS 10.15.7:

code/Common/ZipArchiveIOSystem.cpp:199:50: error: expected ';' after expression
    mapping.zopendisk_file = (opendisk_file_func)opendisk;
                                                 ^
                                                 ;
code/Common/ZipArchiveIOSystem.cpp:199:13: error: no member named 'zopendisk_file' in 'zlib_filefunc_def_s'
    mapping.zopendisk_file = (opendisk_file_func)opendisk;
    ~~~~~~~ ^
code/Common/ZipArchiveIOSystem.cpp:199:31: error: use of undeclared identifier 'opendisk_file_func'
    mapping.zopendisk_file = (opendisk_file_func)opendisk;
                              ^
code/Common/ZipArchiveIOSystem.cpp:199:50: error: expression result unused [-Werror,-Wunused-value]
    mapping.zopendisk_file = (opendisk_file_func)opendisk;
                                                 ^~~~~~~~
4 errors generated.

assimp 5.1.5 didn't have this problem.

[VladyslavTupikin]

Hi, i have the same issue on Arch Linux

gcc (GCC) 11.1.0

   Static hostname: dkpc
         Icon name: computer-desktop
           Chassis: desktop
        Machine ID: a94ff1b5f37a4868a87465dccbce1a1e
           Boot ID: 1bbc8f538be14e04aa409fc74c8f2ff8
  Operating System: Arch Linux
            Kernel: Linux 5.11.8-arch1-1
      Architecture: x86-64

/home/dk/soft/assimp/code/Common/ZipArchiveIOSystem.cpp: In static member function ‘static zlib_filefunc_def Assimp::IOSystem2Unzip::get(Assimp::IO
System*)’:                                                               
/home/dk/soft/assimp/code/Common/ZipArchiveIOSystem.cpp:199:13: error: ‘zlib_filefunc_def’ {aka ‘struct zlib_filefunc_def_s’} has no member named ‘
zopendisk_file’; did you mean ‘zopen_file’?                                                                                                        
  199 |     mapping.zopendisk_file = (opendisk_file_func)opendisk;
      |             ^~~~~~~~~~~~~~
      |             zopen_file
/home/dk/soft/assimp/code/Common/ZipArchiveIOSystem.cpp:199:31: error: ‘opendisk_file_func’ was not declared in this scope; did you mean ‘open_file
_func’?                                                                  
  199 |     mapping.zopendisk_file = (opendisk_file_func)opendisk;                                                                                 
      |                               ^~~~~~~~~~~~~~~~~~
      |                               open_file_func
[  5%] Building CXX object code/CMakeFiles/assimp.dir/Common/Subdivision.cpp.o
[  6%] Building CXX object code/CMakeFiles/assimp.dir/Common/scene.cpp.o
make[2]: *** [code/CMakeFiles/assimp.dir/build.make:186: code/CMakeFiles/assimp.dir/Common/ZipArchiveIOSystem.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:182: code/CMakeFiles/assimp.dir/all] Error 2
make: *** [Makefile:149: all] Error 2

[kimkulling]

Pretty bad, thanks for the report. We will take care.

[umlaeute]

and of course we have a similar problem for the Debian packages...

however, i'm a bit confused.

i see that the unzip implementation in contrib/ does provide the missing typedefs and struct members.
now, in Debian we make sure to use system libraries instead of vendored libraries (completely ditching contrib/unzip/) and the libminizip-dev system library does not provide the typedefs/members.

however, i would have thought that "ordinary builds" (that is: what practically every user who downloads the assimp sources and builds them would do) would use the vendored library...

and why is the CI building successfully?

---

anyhow:
it seems this is yet another problem with #3556 (Update unzip contrib), similar to #3591

it's a bit unfortunate that #3556 updated the "unzip contrib" without mentioning where the sources actually came from.

luckily there's also #4324, where @alpire hints that these changes come

from https://github.com/hunter-packages/minizip. That repo itself is an old fork of minizip-ng. minizip-ng removed zopendisk_file in 2017.

i suggest to stay compatible with mainstream implementations (rather than some unmaintained forks)
(and possibly open some issue with the hunter packages)

[tkircher]

I also ran into this issue, on a clean Ubuntu 20.04.3 LTS system with the relevant system libraries installed. There seem to be numerous projects these days building their own incompatible versions of very common system libraries instead of fixing the code.

[derenv]

also ran into this problem on manjaro! patch from @brechtsanders solved it however.

[yurivict]

@derenv How did you solve it?

[ryandesign]

He used the patch he provided in the last block of code in this bug report.

[derenv]

@derenv How did you solve it?

i used @brechtsanders patch he put in the original post.

[waebbl]

I'm having the same issue on Gentoo Linux while packaging for v5.2.2.
@brechtsanders patch lets the package build, but I'm not sure if it's the right check. The check for ZOPENDISK64 looks like it would pass for zlib_filefunc64_def_s, but seems inappropriate for the zlib_filefunc_def_s struct where it should look more like ZOPENDISK IMO.

[larryxiao625]

这是来自QQ邮箱的自动回复邮件。你的邮件已经收到，我将在尽快给你回复。

[umlaeute]

@ray804 broken chinese autoreply?

@waebbl well, applying the patch allows me to build assimp (which of course is necessary) and the testsuite passes (which i think is a good indication that the fix is also sufficient).