mirror of
https://github.com/jmcnamara/libxlsxwriter.git
synced 2026-05-15 14:15:54 -06:00
[GH-ISSUE #339] Static build of libxlsxwriter with openssl #276
Labels
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
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/libxlsxwriter#276
Loading…
Add table
Add a link
Reference in a new issue
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?
Originally created by @squinky86 on GitHub (Jun 24, 2021).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/339
Originally assigned to: @jmcnamara on GitHub.
I have a project where I'm building libxlsxwriter and openssl statically into it. Unfortunately, both define the MD5 function identically and cause a conflict.
When -DBUILD_SHARED_LIBS=off and -DUSE_OPENSSL_MD5=on, libxlsxwriter's build process should specify that the MD5 function is external.
@jmcnamara commented on GitHub (Jun 24, 2021):
Could you give some example of how to reproduce this?
@squinky86 commented on GitHub (Jun 25, 2021):
Absolutely:
In this example, I built openssl-1.1.1k by cross-compiling into /tmp/openssl-1.1.1k.
pushd /tmp/openssl-1.1.1k && ./Configure mingw64 no-shared no-asm no-err no-tests CROSS_COMPILE=x86_64-w64-mingw32- && make -j3 && popdlibxlsxwriter-1.0.6 was built in /tmp/libxlsxwriter-1.0.6.
Since both libxlsxwriter and openssl now both define the MD5_* functions, I can't link anymore. This is resolved for now by building libxlsxwriter without MD5 support; however, I lose some functionality with this fix.
My suggested fix: if -DBUILD_SHARED_LIBS=off and USE_OPENSSL_MD5 is on, declare the MD5_* functions as "externs" so that they can be linked in. Alternatively, the static build for libxlsxwriter should build in the static openssl library (please don't do this). Another alternative is to use different function names for the internal MD5 routines like they were before.
@jmcnamara commented on GitHub (Jun 25, 2021):
This part of the error message is odd since md5.c shouldn't be compiled into the libxlsxwriter.a with
USE_OPENSSL_MD5=on:When I do the following with the option off I get:
As you can see md5.c.o in included and the symbols are in the Text section. Which all looks okay.
And when I compile with it on:
This time there is no mention of md5.c.o and the symbols are only in the Undefined section. Which again looks okay.
Can you do something similar and check if md5.c is compiled and if the symbols are defined.
BUILD_SHARED_LIBS=offisn't required since that is the default.@jmcnamara commented on GitHub (Jul 1, 2021):
@squinky86 Any update on this?
@squinky86 commented on GitHub (Jul 1, 2021):
Thanks for the reminder! I have the test running at https://ci.appveyor.com/project/squinky86/stigqter/builds/39837129 to see if I can reproduce it. It'll be a couple of hours, and I won't be able to check it until tomorrow.
@jmcnamara commented on GitHub (Jul 1, 2021):
Cool. I'll keep an eye on that.
@squinky86 commented on GitHub (Jul 2, 2021):
Well, I botched that one. Perhaps an OPENSSL_INCLUDE_DIR option could be included as well? Trying again (https://ci.appveyor.com/project/squinky86/stigqter/builds/39847906)...
@jmcnamara commented on GitHub (Jul 2, 2021):
That looks like it passed. Right?
I added
find_package(OpenSSL REQUIRED)to the CMakeLists.txt file on HEAD.On Linux it finds the correct include dir and link files. On macOS I had to prompt it a bit like this:
Could you try that out and see if it works and/or improves things for you. I want to respin a release later today so if you get a chance to test it that would be great.
@squinky86 commented on GitHub (Jul 2, 2021):
That does look like it's working. I'm good closing this issue (and sincerely thank you for your time for helping me debug).
I'll try the OPENSSL_ROOT_DIR on the next build. Thanks!
@jmcnamara commented on GitHub (Jul 3, 2021):
Thanks to you too for the debugging. Closing.
@squinky86 commented on GitHub (Jul 13, 2021):
Hey @jmcnamara - I'm having trouble with 1.0.8+. After cross-compiling openssl in /tmp/openssl-1.1.1k and zlib into /tmp/zlib-1.2.11, I try to build libxlsxwriter with:
cmake -DUSE_STANDARD_TMPFILE=OFF -DCMAKE_TOOLCHAIN_FILE=/tmp/profile.cmake -DBUILD_SHARED_LIBS=OFF -DZLIB_INCLUDE_DIR=/tmp/zlib-1.2.11 -DZLIB_LIBRARY=/tmp/zlib-1.2.11/libzlibstatic.a -DUSE_OPENSSL_MD5=ON -DCMAKE_C_FLAGS=-I/tmp/openssl-1.1.1k/include -DOPENSSL_ROOT_DIR=/tmp/openssl-1.1.1kbut get the following error:
@jmcnamara commented on GitHub (Jul 13, 2021):
@squinky86 what OS are you using? I can't reproduce this on macOS 10.14.6:
@jmcnamara commented on GitHub (Jul 13, 2021):
I also tried the same commands on Fedora 32 and they worked fine as well.
Note that my cmake args are slightly paired down from yours. The
-DZLIB_INCLUDE_DIRand-DZLIB_LIBRARYare result variables rather than input variables and aren't needed (see https://cmake.org/cmake/help/latest/module/FindZLIB.html). I used-DZLIB_ROOTinstead but that isn't relevant to your issue since cmake finds a zlib version. I also left out-DCMAKE_C_FLAGSwhich shouldn't be required.@jmcnamara commented on GitHub (Jul 13, 2021):
Also make sure that libcrypto compiled correctly in your openssl directory. You should have something like:
@squinky86 commented on GitHub (Jul 14, 2021):
Cross-compiling on linux on Ubuntu 20.04 using the g++-mingw-w64-x86-64 package:
/tmp/profile.cmake:
zlib compile:
pushd /tmp/zlib-1.2.11 && cmake ./ -DCMAKE_TOOLCHAIN_FILE=/tmp/profile.cmake -DBUILD_SHARED_LIBS=OFF && make -j3 && popdopenssl compile:
pushd /tmp/openssl-1.1.1k && ./Configure mingw64 no-shared no-asm no-err no-tests CROSS_COMPILE=x86_64-w64-mingw32- && make -j3 && popdlibxlsxwrwiter compile:
pushd /tmp/libxlsxwriter-RELEASE_1.1.0 && cmake -DUSE_STANDARD_TMPFILE=OFF -DCMAKE_TOOLCHAIN_FILE=/tmp/profile.cmake -DBUILD_SHARED_LIBS=OFF -DZLIB_INCLUDE_DIR=/tmp/zlib-1.2.11 -DZLIB_LIBRARY=/tmp/zlib-1.2.11/libzlibstatic.a -DUSE_OPENSSL_MD5=ON -DCMAKE_C_FLAGS=-I/tmp/openssl-1.1.1k/include -DOPENSSL_ROOT_DIR=/tmp/openssl-1.1.1k && make -j3 && popdAttempt 2:
cmake -DUSE_STANDARD_TMPFILE=OFF -DCMAKE_TOOLCHAIN_FILE=/tmp/profile.cmake -DBUILD_SHARED_LIBS=OFF -DZLIB_INCLUDE_DIR=/tmp/zlib-1.2.11 -DZLIB_LIBRARY=/tmp/zlib-1.2.11/libzlibstatic.a -DUSE_OPENSSL_MD5=ON -DCMAKE_C_FLAGS=-I/tmp/openssl-1.1.1k/include -DOPENSSL_CRYPTO_LIBRARY=/tmp/openssl-1.1.1k/libcrypto.a -DOPENSSL_ROOT_DIR=/tmp/openssl-1.1.1kAnd I acknowledge some of the flags are probably redundant at this point. You can probably tell I tried a lot of different things to get this working ;)
@jmcnamara commented on GitHub (Jul 14, 2021):
I was able to reproduce the build issue using your instructions on Fedora 32.
I don't know what the issue is. I suspect that the error message is a bit of a red herring and Cmake can't find libcrypto.a rather than OpenSSL. It may expect a different extension or prefix. I tried a variety of fixes with
OPENSSL_USE_STATIC_LIBSand other workarounds but without success.If I get a chance I'll compile it in a real mingw environment on Windows and see if it gives any clues.
@squinky86 commented on GitHub (Jul 15, 2021):
FYI, I am able to duplicate it in cygwin as well using the mingw64-x86_64-gcc 10.2.0 (stable) and 11.1.0 (testing) packages. This does appear to be more of a weird cmake issue than a libxlsxwriter issue, but I have no idea what needs to be documented to write this up as a cmake bug at this point.
@jmcnamara commented on GitHub (Jul 15, 2021):
I think I found the issue.
This line in
profile.cmakefile puts/usr/before the search paths so that Cmake is looking in/usr/tmpinstead of/tmp:Just comment that out or remove it, unless you have some very specific reason for using it.
I also had to change this line in the Libxlsxwriter CMakeList.txt:
To this:
To avoid an error about a missing CMAKE_CXX_COMPILER but you may have g++ installed. I think I only installed gcc.
Anyway, after those fixes everything compiled for me on Fedora.
@jmcnamara commented on GitHub (Jul 20, 2021):
@squinky86 Any update on this?
@squinky86 commented on GitHub (Apr 6, 2022):
For anyone coming from google: adding "/" to the CMAKE_FIND_ROOT_PATH also resolved this. It's all working now - thanks!