Hello together,
I'm trying to compile the Zint backend with my latest Microsoft C compiler (MSVC 14.1 from VS2017, 64-bit). So I have created a clone of the Sourceforge GIT repository. It's on commit 059eb7e4503e41e27d7befcbfd2c2dfbe1017206 ("tcl backend update to version 2.6.4" by Harald Oehlmann at 2018-11-02), master branch.
Then I tried to setup the build using CMake with "NMake Makefiles" generator. That worked but the compiler complained about
It seems that MSVC does not require an explicit link to the math library. So I put it in a if/endif statement in the backend's CMake configuration file. The prefix "-l" has been removed because CMake can handle this automatically and takes into account platform/compiler specific differences.
The reason for the missing import library was the absence of any exported symbols, which was caused by a missing macro definition (DLL_EXPORT). To fix this, I added a related statement in the configuration file depending on MSVC and the CMake variable "BUILD_SHARED_LIBS". It is used to control whether to create shared or static libraries.
I have added a related GIT patch for the case you want to apply the changes. You may need to counter-check the changes on other systems.
By the way, the VS-project in "win32" is outdated. At least two source files are missing.
And the "zint.exe" application did not compile with the described CMake setup because of missing symbols
getopt_longoptargoptindThese symbols seem to originate from GNU C library code (getopt) included in the project but I did not investigate how to fix it.
With the changes described above, the backend compiles and installs. But unfortunately I cannot say if it works. The project using Zint gets migrated and still needs a lot of time before it can compile and execute.
I hope this helps.
Kind regards
C. Scharenberg
Dear C. Scharrenberg,
the patch looks reasonable and will be integrated soon. Thank you for that.
I personally only maintain the MS-VC6 makefile for zint.exe and the qmake infrastructure for qzint.
I mainly face issues in windows compilation due to the dependencies on png and zip.
Thats why I maintain detailed build instructions for those two make targets.
The others are community driven (like you) and may be removed at any time if they cause more troubble than help. So you may advice me to change or remove other makefiles. I always favor for "remove" ;-)
Thank you,
Harald
Hello Harald,
That's fine with me. Thank you for support.
I fully understand that you want to keep the effort of build system maintenance small. But exactly that is a good reason for choosing CMake:
So you get all in one setup. Fine tuning of course can be done by the community...
Kind regards
Christoph
Committed by [9684bd]
Closed.
Thank you,
Harald
Related
Commit: [9684bd]