github-starred/libxlsxwriter
2
0
Fork 0
mirror of https://github.com/jmcnamara/libxlsxwriter.git synced 2026-05-15 14:15:54 -06:00
Code Issues 16 Projects Packages Wiki Activity Actions

[GH-ISSUE #115] Link zlib when building shared library with MinGW-w64 #95

New issue
Closed
opened 2026-05-05 11:39:01 -06:00 by gitea-mirror · 28 comments
gitea-mirror commented 2026-05-05 11:39:01 -06:00
Owner
Copy link

Originally created by @ohmyarch on GitHub (Jul 28, 2017).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/115

Originally assigned to: @jmcnamara on GitHub.

CMakeFiles/xlsxwriter.dir/objects.a(zip.c.obj): In function 'zipWriteInFileInZip':
libxlsxwriter/third_party/minizip/zip.c:1414: undefined reference to 'crc32'
...

Originally created by @ohmyarch on GitHub (Jul 28, 2017). Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/115 Originally assigned to: @jmcnamara on GitHub. CMakeFiles/xlsxwriter.dir/objects.a(zip.c.obj): In function 'zipWriteInFileInZip': libxlsxwriter/third_party/minizip/zip.c:1414: undefined reference to 'crc32' ...
gitea-mirror 2026-05-05 11:39:01 -06:00
gitea-mirror commented 2026-05-05 11:39:06 -06:00
Author
Owner
Copy link

@jmcnamara commented on GitHub (Jul 29, 2017):

@Alexhuszagh could you take a look at this.

@ohmyarch could you add the command line you used and the build environment.

<!-- gh-comment-id:318789434 --> @jmcnamara commented on GitHub (Jul 29, 2017): @Alexhuszagh could you take a look at this. @ohmyarch could you add the command line you used and the build environment.
gitea-mirror commented 2026-05-05 11:39:09 -06:00
Author
Owner
Copy link

@ohmyarch commented on GitHub (Jul 29, 2017):

@jmcnamara https://tea-ci.org/ohmyarch/libxlsxwriter/1

<!-- gh-comment-id:318801483 --> @ohmyarch commented on GitHub (Jul 29, 2017): @jmcnamara https://tea-ci.org/ohmyarch/libxlsxwriter/1
gitea-mirror commented 2026-05-05 11:39:10 -06:00
Author
Owner
Copy link

@jmcnamara commented on GitHub (Jul 29, 2017):

@ohmyarch

Are you compiling this in MSYS? (Update: since the log is tea-ci I guess you are. Using the .drone.yml.)

Does it work with a 64bit target?

For a 32bit build do you have to install 32bit versions of the zlib-devel libraries?

<!-- gh-comment-id:318813854 --> @jmcnamara commented on GitHub (Jul 29, 2017): @ohmyarch Are you compiling this in MSYS? (Update: since the log is tea-ci I guess you are. Using the .drone.yml.) Does it work with a 64bit target? For a 32bit build do you have to install 32bit versions of the zlib-devel libraries?
gitea-mirror commented 2026-05-05 11:39:11 -06:00
Author
Owner
Copy link

@jmcnamara commented on GitHub (Jul 29, 2017):

Also can you try the standard make system for libxlsxwriter: http://libxlsxwriter.github.io/getting_started.html

<!-- gh-comment-id:318813886 --> @jmcnamara commented on GitHub (Jul 29, 2017): Also can you try the standard make system for libxlsxwriter: http://libxlsxwriter.github.io/getting_started.html
gitea-mirror commented 2026-05-05 11:39:13 -06:00
Author
Owner
Copy link

@ohmyarch commented on GitHub (Jul 29, 2017):

I have tried both 32bit and 64bit build, the same error. All 32bit/64bit static/shared zlib libraries was installed. CMakeLists.txt need some correction to link zlib library when building shared libxlsxwriter library with MinGW-w64.

In addition, standard linux build(static/shared) and mingw static library build works fine.

<!-- gh-comment-id:318831007 --> @ohmyarch commented on GitHub (Jul 29, 2017): I have tried both 32bit and 64bit build, the same error. All 32bit/64bit static/shared zlib libraries was installed. CMakeLists.txt need some correction to link zlib library when building shared libxlsxwriter library with MinGW-w64. In addition, standard linux build(static/shared) and mingw static library build works fine.
gitea-mirror commented 2026-05-05 11:39:15 -06:00
Author
Owner
Copy link

@Alexhuszagh commented on GitHub (Jul 31, 2017):

Hi @jmcnamara, sorry for the late response, I've tried to stop doing work on weekends and am writing my thesis. I'll look into this later today.

@ohmyarch, let me check the configuration. Nothing in the CMakeLists should be dependent on a shared library, since it finds the system's installation.

<!-- gh-comment-id:319175795 --> @Alexhuszagh commented on GitHub (Jul 31, 2017): Hi @jmcnamara, sorry for the late response, I've tried to stop doing work on weekends and am writing my thesis. I'll look into this later today. @ohmyarch, let me check the configuration. Nothing in the CMakeLists should be dependent on a shared library, since it finds the system's installation.
gitea-mirror commented 2026-05-05 11:39:16 -06:00
Author
Owner
Copy link

@jmcnamara commented on GitHub (Jul 31, 2017):

@Alexhuszagh Don't worry about it. Stick with your thesis.

<!-- gh-comment-id:319213376 --> @jmcnamara commented on GitHub (Jul 31, 2017): @Alexhuszagh Don't worry about it. Stick with your thesis.
gitea-mirror commented 2026-05-05 11:39:18 -06:00
Author
Owner
Copy link

@jmcnamara commented on GitHub (Aug 1, 2017):

@ohmyarch Correction I do see the issue now.

<!-- gh-comment-id:319418232 --> @jmcnamara commented on GitHub (Aug 1, 2017): @ohmyarch Correction I do see the issue now.
gitea-mirror commented 2026-05-05 11:39:19 -06:00
Author
Owner
Copy link

@jmcnamara commented on GitHub (Aug 1, 2017):

@ohmyarch and @Alexhuszagh It looks like the shared lib isn't linked with -lz. Adding that to the link command in CMakeFiles/xlsxwriter.dir/link.txt fixes the issue. We just need to figure out how to add that to the Cmake script.

<!-- gh-comment-id:319423624 --> @jmcnamara commented on GitHub (Aug 1, 2017): @ohmyarch and @Alexhuszagh It looks like the shared lib isn't linked with `-lz`. Adding that to the link command in `CMakeFiles/xlsxwriter.dir/link.txt` fixes the issue. We just need to figure out how to add that to the Cmake script.
gitea-mirror commented 2026-05-05 11:39:21 -06:00
Author
Owner
Copy link

@jmcnamara commented on GitHub (Aug 1, 2017):

I tried different variations of the following in CMakeLists.txt but it didn't work because they add the flag to the start of the compile list instead of the end.

set(CMAKE_SHARED_LINKER_FLAGS "-lz")

The same effect occurs with:

 cmake -DBUILD_STATIC=OFF -DCMAKE_BUILD_TYPE=Release -DIOAPI_NO_64=ON \
   -DCMAKE_SHARED_LINKER_FLAGS="-lz"  .
<!-- gh-comment-id:319441609 --> @jmcnamara commented on GitHub (Aug 1, 2017): I tried different variations of the following in CMakeLists.txt but it didn't work because they add the flag to the start of the compile list instead of the end. ``` set(CMAKE_SHARED_LINKER_FLAGS "-lz") ``` The same effect occurs with: ``` cmake -DBUILD_STATIC=OFF -DCMAKE_BUILD_TYPE=Release -DIOAPI_NO_64=ON \ -DCMAKE_SHARED_LINKER_FLAGS="-lz" . ```
gitea-mirror commented 2026-05-05 11:39:24 -06:00
Author
Owner
Copy link

@Alexhuszagh commented on GitHub (Aug 1, 2017):

@jmcnamara The target_link_libraries and find_package(ZLIB, ...) should automatically add those in. If -lz is not getting added in, there's a bug in the logic with those steps somewhere.

There's no reason to manually add -lz, since that won't work with custom zlib install directories (users can provide ZLIB_INSTALL_DIR and ZLIB_LIBRARY on the command line to override the system install locations), nor will it work with MSVC. Let me take a look at my logic.

<!-- gh-comment-id:319462657 --> @Alexhuszagh commented on GitHub (Aug 1, 2017): @jmcnamara The `target_link_libraries` and `find_package(ZLIB, ...)` should automatically add those in. If `-lz` is not getting added in, there's a bug in the logic with those steps somewhere. There's no reason to manually add `-lz`, since that won't work with custom zlib install directories (users can provide `ZLIB_INSTALL_DIR` and `ZLIB_LIBRARY` on the command line to override the system install locations), nor will it work with MSVC. Let me take a look at my logic.
gitea-mirror commented 2026-05-05 11:39:29 -06:00
Author
Owner
Copy link

@Alexhuszagh commented on GitHub (Sep 8, 2017):

Hi @jmcnamara, sorry for the long delay but I was unable to find time until now. I just defended my thesis earlier this week, so I will be able to look over this tonight.

<!-- gh-comment-id:328226589 --> @Alexhuszagh commented on GitHub (Sep 8, 2017): Hi @jmcnamara, sorry for the long delay but I was unable to find time until now. I just defended my thesis earlier this week, so I will be able to look over this tonight.
gitea-mirror commented 2026-05-05 11:39:32 -06:00
Author
Owner
Copy link

@jmcnamara commented on GitHub (Sep 11, 2017):

@Alexhuszagh There is no rush.

<!-- gh-comment-id:328674497 --> @jmcnamara commented on GitHub (Sep 11, 2017): @Alexhuszagh There is no rush.
gitea-mirror commented 2026-05-05 11:39:34 -06:00
Author
Owner
Copy link

@Alexhuszagh commented on GitHub (Oct 18, 2017):

Hi @jmcnamara, I should have the patch for this. Between life events and my Windows dev computer crashing, I really haven't had time for this. I'm testing it on a naive virtual machine and then publishing it.

<!-- gh-comment-id:337515550 --> @Alexhuszagh commented on GitHub (Oct 18, 2017): Hi @jmcnamara, I should have the patch for this. Between life events and my Windows dev computer crashing, I really haven't had time for this. I'm testing it on a naive virtual machine and then publishing it.
gitea-mirror commented 2026-05-05 11:39:36 -06:00
Author
Owner
Copy link

@jmcnamara commented on GitHub (Oct 18, 2017):

@Alexhuszagh no worries. I'm not sure that this is actually an issue.

I was able to reproduce it in MSYS2 32 and 64 bit a few months ago but not in Linux so my feeling was that it was probably a cmake or other issue.

Anyway I tried to reproduce it today with the latest MSYS2 (20161025 builds) and I can't:

pacman -S --noconfirm git gcc make cmake zlib-devel

git clone https://github.com/jmcnamara/libxlsxwriter.git

cd libxlsxwriter/
cd cmake
cmake -DBUILD_STATIC=OFF -DCMAKE_BUILD_TYPE=Release -DIOAPI_NO_64=ON ..

Output:

MSYS ~/libxlsxwriter/cmake
$ cmake -DBUILD_STATIC=OFF -DCMAKE_BUILD_TYPE=Release -DIOAPI_NO_64=ON ..
-- The C compiler identification is GNU 5.3.0
-- Defining WIN32 under MSYS due to CMAKE_LEGACY_CYGWIN_WIN32
-- Check for working C compiler: /usr/bin/cc.exe
-- Check for working C compiler: /usr/bin/cc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- The CXX compiler identification is GNU 5.3.0
-- Check for working CXX compiler: /usr/bin/c++.exe
-- Check for working CXX compiler: /usr/bin/c++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test ZLIB_COMPILES
-- Performing Test ZLIB_COMPILES - Success
Found ZLIB.
zlib version: 1.2.8
-- Configuring done
-- Generating done
-- Build files have been written to: /home/jmcnamara/libxlsxwriter/cmake

So everything looks okay.

@ohmyarch can you confirm? And then rerun your tea-ci job.

<!-- gh-comment-id:337562388 --> @jmcnamara commented on GitHub (Oct 18, 2017): @Alexhuszagh no worries. I'm not sure that this is actually an issue. I was able to reproduce it in MSYS2 32 and 64 bit a few months ago but not in Linux so my feeling was that it was probably a cmake or other issue. Anyway I tried to reproduce it today with the latest [MSYS2 ](http://www.msys2.org/) (20161025 builds) and I can't: ```bash pacman -S --noconfirm git gcc make cmake zlib-devel git clone https://github.com/jmcnamara/libxlsxwriter.git cd libxlsxwriter/ cd cmake cmake -DBUILD_STATIC=OFF -DCMAKE_BUILD_TYPE=Release -DIOAPI_NO_64=ON .. ``` Output: ```bash MSYS ~/libxlsxwriter/cmake $ cmake -DBUILD_STATIC=OFF -DCMAKE_BUILD_TYPE=Release -DIOAPI_NO_64=ON .. -- The C compiler identification is GNU 5.3.0 -- Defining WIN32 under MSYS due to CMAKE_LEGACY_CYGWIN_WIN32 -- Check for working C compiler: /usr/bin/cc.exe -- Check for working C compiler: /usr/bin/cc.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- The CXX compiler identification is GNU 5.3.0 -- Check for working CXX compiler: /usr/bin/c++.exe -- Check for working CXX compiler: /usr/bin/c++.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Performing Test ZLIB_COMPILES -- Performing Test ZLIB_COMPILES - Success Found ZLIB. zlib version: 1.2.8 -- Configuring done -- Generating done -- Build files have been written to: /home/jmcnamara/libxlsxwriter/cmake ``` So everything looks okay. @ohmyarch can you confirm? And then rerun your tea-ci job.
gitea-mirror commented 2026-05-05 11:39:37 -06:00
Author
Owner
Copy link

@Alexhuszagh commented on GitHub (Oct 18, 2017):

@jmcnamara I cannot reproduce the above issue if the runtime flags or library architecture is correct. However, if I link to an incorrect ZLIB library, I get the exact compiler warnings @ohmyarch was warning about. Be very careful about the linked ZLIB variant, if you are worried about potential linker issues, you may always build a static version with the same runtime flags (on MSVC) and architecture, and pass the ZLIB_INCLUDE_DIR and ZLIB_LIBRARY to CMake during configuration.

I did require a few minor patches to fix a few minor issues (and suppress the MSVC security warnings, since they promote a non-standard API), so I will be committing those. One of the patches involved ZLIB linking to the library, so it's very likely the cause of @ohmyarch's issues, even if I couldn't reproduce his errors on my machine.

For the following tests, I used the system ZLIB for MSYS2 (installed for the appropriate architecture via Pacman).

Tested Configurations

  • MSVC, 2015, 32-bit, "/MD", BUILD_STATIC=OFF
  • MSVC, 2015, 64-bit, "/MD", BUILD_STATIC=OFF
  • MSVC, 2015, 32-bit, "/MT", BUILD_STATIC=ON
  • MSVC, 2015, 64-bit, "/MT", BUILD_STATIC=ON
  • MSYS2, 64-bit, BUILD_STATIC=OFF
  • MSYS2, 64-bit, BUILD_STATIC=ON

Generators

Compiler Architecture Flag
MSVC 32 "Visual Studio 14 2015"
MSVC 64 "Visual Studio 14 2015 Win64"
MSYS2 N/A "MSYS Makefiles"

Build Command

Download

wget http://zlib.net/zlib-1.2.11.tar.gz
tar xvf zlib-1.2.11.tar.gz

Build ZLIB

MSVC

# `RUNTIME` is "/MT" for static runtime, "/MD" for DLL runtime
cmake -G %GEN% -DCMAKE_C_FLAGS_RELEASE="%RUNTIME%"
cmake --build . --config Release

Build Library

MSVC

# `ZLIB_LIBRARY_NAME` is either `zlib` (for shared), or `zlibstatic` (for static)
# `ZLIB_HOME` is the path to the ZLIB directory
# `RUNTIME` is "/MT" for static runtime, "/MD" for DLL runtime
cmake -G %GEN% -DCMAKE_CXX_FLAGS_RELEASE="%RUNTIME%" -DBUILD_STATIC=%STATIC% -DBUILD_TESTS=ON -DZLIB_INCLUDE_DIR=%ZLIB_HOME% -DZLIB_LIBRARY=%ZLIB_HOME%\Release\%ZLIB_LIBRARY_NAME%.lib
cmake --build . --config Release

MSYS2

cmake -G %GEN% -DBUILD_STATIC=$STATIC -DBUILD_TESTS=ON
cmake --build . --config Release
<!-- gh-comment-id:337653829 --> @Alexhuszagh commented on GitHub (Oct 18, 2017): @jmcnamara I cannot reproduce the above issue if the runtime flags or library architecture is correct. However, if I link to an incorrect ZLIB library, I get the exact compiler warnings @ohmyarch was warning about. Be very careful about the linked ZLIB variant, if you are worried about potential linker issues, you may always build a static version with the same runtime flags (on MSVC) and architecture, and pass the `ZLIB_INCLUDE_DIR` and `ZLIB_LIBRARY` to CMake during configuration. I did require a few minor patches to fix a few minor issues (and suppress the MSVC security warnings, since they promote a non-standard API), so I will be committing those. One of the patches involved ZLIB linking to the library, so it's very likely the cause of @ohmyarch's issues, even if I couldn't reproduce his errors on my machine. For the following tests, I used the system ZLIB for MSYS2 (installed for the appropriate architecture via Pacman). # Tested Configurations - MSVC, 2015, 32-bit, "/MD", `BUILD_STATIC=OFF` - MSVC, 2015, 64-bit, "/MD", `BUILD_STATIC=OFF` - MSVC, 2015, 32-bit, "/MT", `BUILD_STATIC=ON` - MSVC, 2015, 64-bit, "/MT", `BUILD_STATIC=ON` - MSYS2, 64-bit, `BUILD_STATIC=OFF` - MSYS2, 64-bit, `BUILD_STATIC=ON` # Generators | Compiler | Architecture | Flag | |:------------:|:----------------:|:------:| | MSVC | 32 | "Visual Studio 14 2015" | | MSVC | 64 | "Visual Studio 14 2015 Win64" | | MSYS2 | N/A | "MSYS Makefiles" | # Build Command ## Download ```bash wget http://zlib.net/zlib-1.2.11.tar.gz tar xvf zlib-1.2.11.tar.gz ``` ## Build ZLIB **MSVC** ``` # `RUNTIME` is "/MT" for static runtime, "/MD" for DLL runtime cmake -G %GEN% -DCMAKE_C_FLAGS_RELEASE="%RUNTIME%" cmake --build . --config Release ``` ## Build Library **MSVC** ``` # `ZLIB_LIBRARY_NAME` is either `zlib` (for shared), or `zlibstatic` (for static) # `ZLIB_HOME` is the path to the ZLIB directory # `RUNTIME` is "/MT" for static runtime, "/MD" for DLL runtime cmake -G %GEN% -DCMAKE_CXX_FLAGS_RELEASE="%RUNTIME%" -DBUILD_STATIC=%STATIC% -DBUILD_TESTS=ON -DZLIB_INCLUDE_DIR=%ZLIB_HOME% -DZLIB_LIBRARY=%ZLIB_HOME%\Release\%ZLIB_LIBRARY_NAME%.lib cmake --build . --config Release ``` **MSYS2** ``` cmake -G %GEN% -DBUILD_STATIC=$STATIC -DBUILD_TESTS=ON cmake --build . --config Release ```
gitea-mirror commented 2026-05-05 11:39:39 -06:00
Author
Owner
Copy link

@ohmyarch commented on GitHub (Oct 19, 2017):

@Alexhuszagh Now the shared library can be built , but libxlsxwriter.dll will not be installed after executing make install.

<!-- gh-comment-id:337904683 --> @ohmyarch commented on GitHub (Oct 19, 2017): @Alexhuszagh Now the shared library can be built , but libxlsxwriter.dll will not be installed after executing `make install`.
gitea-mirror commented 2026-05-05 11:39:41 -06:00
Author
Owner
Copy link

@Alexhuszagh commented on GitHub (Oct 19, 2017):

@ohmyarch Can you please post the output of make VERBOSE=1 install? I'll be debugging this today.

<!-- gh-comment-id:337999657 --> @Alexhuszagh commented on GitHub (Oct 19, 2017): @ohmyarch Can you please post the output of `make VERBOSE=1 install`? I'll be debugging this today.
gitea-mirror commented 2026-05-05 11:39:45 -06:00
Author
Owner
Copy link

@Alexhuszagh commented on GitHub (Oct 19, 2017):

At the very least, I will be submitting a PR today to test the MSVC and MinGW target installs using AppVeyor and Tea-CI, so this issue does not occur again.

<!-- gh-comment-id:338040876 --> @Alexhuszagh commented on GitHub (Oct 19, 2017): At the very least, I will be submitting a PR today to test the MSVC and MinGW target installs using AppVeyor and Tea-CI, so this issue does not occur again.
gitea-mirror commented 2026-05-05 11:39:46 -06:00
Author
Owner
Copy link

@ohmyarch commented on GitHub (Oct 20, 2017):

@Alexhuszagh https://paste.kde.org/pcpx9ekat/j8swm1/raw

<!-- gh-comment-id:338081562 --> @ohmyarch commented on GitHub (Oct 20, 2017): @Alexhuszagh https://paste.kde.org/pcpx9ekat/j8swm1/raw
gitea-mirror commented 2026-05-05 11:39:48 -06:00
Author
Owner
Copy link

@Alexhuszagh commented on GitHub (Oct 22, 2017):

@ohmyarch Is everything working like expected now?

<!-- gh-comment-id:338501518 --> @Alexhuszagh commented on GitHub (Oct 22, 2017): @ohmyarch Is everything working like expected now?
gitea-mirror commented 2026-05-05 11:39:50 -06:00
Author
Owner
Copy link

@ohmyarch commented on GitHub (Oct 23, 2017):

@Alexhuszagh For MinGW-w64, *.dll should be installed to ${CMAKE_INSTALL_PREFIX}/bin.

<!-- gh-comment-id:338693927 --> @ohmyarch commented on GitHub (Oct 23, 2017): @Alexhuszagh For MinGW-w64, *.dll should be installed to ${CMAKE_INSTALL_PREFIX}/bin.
gitea-mirror commented 2026-05-05 11:39:51 -06:00
Author
Owner
Copy link

@jmcnamara commented on GitHub (Oct 23, 2017):

@ohmyarch why in bin? Shouldn't it go into lib?

<!-- gh-comment-id:338696411 --> @jmcnamara commented on GitHub (Oct 23, 2017): @ohmyarch why in `bin`? Shouldn't it go into `lib`?
gitea-mirror commented 2026-05-05 11:39:53 -06:00
Author
Owner
Copy link

@Alexhuszagh commented on GitHub (Oct 23, 2017):

@jmcnamara He, @ohmyarch, is actually right here. I never get this right, because "DLL" is supposed to go in the bin folder, has a "DllMain" function and has the same file format, despite it being a dynamically linked library and being identified as a library in the header. It's a counter-intuitive reality of Windows, and it's how most libraries do things (including ZLIB, our dependency). It's a 3 character patch.

<!-- gh-comment-id:338808444 --> @Alexhuszagh commented on GitHub (Oct 23, 2017): @jmcnamara He, @ohmyarch, is actually right here. I never get this right, because "DLL" is supposed to go in the bin folder, has a "DllMain" function and has the same file format, despite it being a dynamically linked library and being identified as a library in the header. It's a counter-intuitive reality of Windows, and it's how most libraries do things (including ZLIB, our dependency). It's a 3 character patch.
gitea-mirror commented 2026-05-05 11:39:55 -06:00
Author
Owner
Copy link

@jmcnamara commented on GitHub (Oct 24, 2017):

@ohmyarch This fix is merged upstream into master. Can you test it.

<!-- gh-comment-id:338938044 --> @jmcnamara commented on GitHub (Oct 24, 2017): @ohmyarch This fix is merged upstream into master. Can you test it.
gitea-mirror commented 2026-05-05 11:39:57 -06:00
Author
Owner
Copy link

@ohmyarch commented on GitHub (Oct 24, 2017):

@jmcnamara @Alexhuszagh Everything is now working as expected, thanks. 🎉👍

<!-- gh-comment-id:339035426 --> @ohmyarch commented on GitHub (Oct 24, 2017): @jmcnamara @Alexhuszagh Everything is now working as expected, thanks. 🎉👍
gitea-mirror commented 2026-05-05 11:40:01 -06:00
Author
Owner
Copy link

@jmcnamara commented on GitHub (Oct 24, 2017):

Great. Thanks @ohmyarch and @Alexhuszagh.

<!-- gh-comment-id:339036298 --> @jmcnamara commented on GitHub (Oct 24, 2017): Great. Thanks @ohmyarch and @Alexhuszagh.
gitea-mirror commented 2026-05-05 11:40:04 -06:00
Author
Owner
Copy link

@lattice0 commented on GitHub (Mar 2, 2020):

@Alexhuszagh no worries. I'm not sure that this is actually an issue.

I was able to reproduce it in MSYS2 32 and 64 bit a few months ago but not in Linux so my feeling was that it was probably a cmake or other issue.

Anyway I tried to reproduce it today with the latest MSYS2 (20161025 builds) and I can't:

pacman -S --noconfirm git gcc make cmake zlib-devel

git clone https://github.com/jmcnamara/libxlsxwriter.git

cd libxlsxwriter/
cd cmake
cmake -DBUILD_STATIC=OFF -DCMAKE_BUILD_TYPE=Release -DIOAPI_NO_64=ON ..

Output:

MSYS ~/libxlsxwriter/cmake
$ cmake -DBUILD_STATIC=OFF -DCMAKE_BUILD_TYPE=Release -DIOAPI_NO_64=ON ..
-- The C compiler identification is GNU 5.3.0
-- Defining WIN32 under MSYS due to CMAKE_LEGACY_CYGWIN_WIN32
-- Check for working C compiler: /usr/bin/cc.exe
-- Check for working C compiler: /usr/bin/cc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- The CXX compiler identification is GNU 5.3.0
-- Check for working CXX compiler: /usr/bin/c++.exe
-- Check for working CXX compiler: /usr/bin/c++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test ZLIB_COMPILES
-- Performing Test ZLIB_COMPILES - Success
Found ZLIB.
zlib version: 1.2.8
-- Configuring done
-- Generating done
-- Build files have been written to: /home/jmcnamara/libxlsxwriter/cmake

So everything looks okay.

@ohmyarch can you confirm? And then rerun your tea-ci job.

thanks, I was getting this while compiling with qt5 static in MSYS2/MinGW and didn't know I had to instal the devel version of zlib, I was installing the release one

<!-- gh-comment-id:593173896 --> @lattice0 commented on GitHub (Mar 2, 2020): > @Alexhuszagh no worries. I'm not sure that this is actually an issue. > > I was able to reproduce it in MSYS2 32 and 64 bit a few months ago but not in Linux so my feeling was that it was probably a cmake or other issue. > > Anyway I tried to reproduce it today with the latest [MSYS2 ](http://www.msys2.org/) (20161025 builds) and I can't: > > ```shell > pacman -S --noconfirm git gcc make cmake zlib-devel > > git clone https://github.com/jmcnamara/libxlsxwriter.git > > cd libxlsxwriter/ > cd cmake > cmake -DBUILD_STATIC=OFF -DCMAKE_BUILD_TYPE=Release -DIOAPI_NO_64=ON .. > ``` > > Output: > > ```shell > MSYS ~/libxlsxwriter/cmake > $ cmake -DBUILD_STATIC=OFF -DCMAKE_BUILD_TYPE=Release -DIOAPI_NO_64=ON .. > -- The C compiler identification is GNU 5.3.0 > -- Defining WIN32 under MSYS due to CMAKE_LEGACY_CYGWIN_WIN32 > -- Check for working C compiler: /usr/bin/cc.exe > -- Check for working C compiler: /usr/bin/cc.exe -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- The CXX compiler identification is GNU 5.3.0 > -- Check for working CXX compiler: /usr/bin/c++.exe > -- Check for working CXX compiler: /usr/bin/c++.exe -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Performing Test ZLIB_COMPILES > -- Performing Test ZLIB_COMPILES - Success > Found ZLIB. > zlib version: 1.2.8 > -- Configuring done > -- Generating done > -- Build files have been written to: /home/jmcnamara/libxlsxwriter/cmake > ``` > > So everything looks okay. > > @ohmyarch can you confirm? And then rerun your tea-ci job. thanks, I was getting this while compiling with qt5 static in MSYS2/MinGW and didn't know I had to instal the devel version of zlib, I was installing the release one
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
coverity
cmake-improvements
cmake_pkgconfig_fix
ctest
button
tables
autofilter
dtoa
iwyu
openssl
gentoo
gh310
condition_format
rich_string_html
header_footer_images
custom_data_labels
object_position
gh265
constant_mode_comments2
constant_mode_comments
vml
md5
vcpkg
hyperlinks
api_refactor
win_fopen
gh203
rich_strings
chartsheet
in_mem_image
gh192
revert-162-master
data_validation
meson
charts
scan_build
utf8_strlen
tmpfileplus
custom_properties
insert_image
default_row
control_chars
worksheet_protect
dev
red_black
panes
mkstemp
defined_names
optimise
wip
v1.2.4
v1.2.3
v1.2.2
v1.2.1
v1.2.0
v1.1.9
v1.1.8
RELEASE_1.1.7
RELEASE_1.1.6
RELEASE_1.1.5
RELEASE_1.1.4
RELEASE_1.1.3
RELEASE_1.1.2
RELEASE_1.1.1
RELEASE_1.1.0
RELEASE_1.0.9
RELEASE_1.0.8
RELEASE_1.0.7
RELEASE_1.0.6
RELEASE_1.0.5
RELEASE_1.0.4
RELEASE_1.0.3
RELEASE_1.0.2
RELEASE_1.0.1
RELEASE_1.0.0
RELEASE_0.9.9
RELEASE_0.9.8
RELEASE_0.9.7
RELEASE_0.9.6
RELEASE_0.9.5
RELEASE_0.9.4
RELEASE_0.9.3
RELEASE_0.9.2
RELEASE_0.9.1
RELEASE_0.9.0
RELEASE_0.8.9
RELEASE_0.8.8
RELEASE_0.8.7
RELEASE_0.8.6
RELEASE_0.8.5
RELEASE_0.8.4
RELEASE_0.8.3
RELEASE_0.8.2
RELEASE_0.8.1
RELEASE_0.8.0
RELEASE_0.7.9
RELEASE_0.7.8
RELEASE_0.7.7
RELEASE_0.7.6
RELEASE_0.7.5
RELEASE_0.7.4
RELEASE_0.7.3
RELEASE_0.7.2
RELEASE_0.7.1
RELEASE_0.7.0
RELEASE_0.6.9
RELEASE_0.6.8
RELEASE_0.6.7
RELEASE_0.6.6
RELEASE_0.6.5
RELEASE_0.6.4
RELEASE_0.6.3
RELEASE_0.6.2
RELEASE_0.6.1
RELEASE_0.6.0
RELEASE_0.5.9
RELEASE_0.5.8
RELEASE_0.5.7
RELEASE_0.5.6
RELEASE_0.5.5
RELEASE_0.5.4
RELEASE_0.5.3
RELEASE_0.5.2
RELEASE_0.5.1
RELEASE_0.5.0
RELEASE_0.4.9
RELEASE_0.4.8
RELEASE_0.4.7
RELEASE_0.4.6
RELEASE_0.4.5
RELEASE_0.4.4
RELEASE_0.4.3
RELEASE_0.4.2
RELEASE_0.4.1
RELEASE_0.4.0
RELEASE_0.3.9
RELEASE_0.3.8
RELEASE_0.3.7
RELEASE_0.3.6
RELEASE_0.3.5
RELEASE_0.3.4
RELEASE_0.3.3
RELEASE_0.3.2
RELEASE_0.3.1
RELEASE_0.3.0
RELEASE_0.2.9
RELEASE_0.2.8
RELEASE_0.2.7
RELEASE_0.2.6
RELEASE_0.2.5
RELEASE_0.2.4
RELEASE_0.2.3
RELEASE_0.2.2
RELEASE_0.2.1
RELEASE_0.2.0
RELEASE_0.1.9
RELEASE_0.1.8
RELEASE_0.1.7
RELEASE_0.1.6
RELEASE_0.1.5
RELEASE_0.1.4
RELEASE_0.1.3
RELEASE_0.1.2
RELEASE_0.1.1
RELEASE_0.1.0
RELEASE_0.0.9
RELEASE_0.0.8
RELEASE_0.0.7
RELEASE_0.0.6
RELEASE_0.0.5
RELEASE_0.0.4
RELEASE_0.0.3
RELEASE_0.0.2
RELEASE_0.0.1
Labels
Clear labels   
awaiting user feedback

   
bug

   
cmake

   
cmake

   
docs

   
feature request

   
in progress

   
long term

   
medium term

   
medium term

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
question

   
ready to close

   
short term

   
under investigation

   
wontfix
No labels
awaiting user feedback
bug
cmake
cmake
docs
feature request
in progress
long term
medium term
medium term
pull-request
question
question
ready to close
short term
under investigation
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/libxlsxwriter#95
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?