-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make / cmake inconsistencies #2261
Comments
I'm currently using this patch to support ZSTD_PROGRAMS_LINK_SHARED in the make context.
|
Here is a slightly different proposal. Rather than dropping
The unuseful zstd-dll target is discarded. I plan to do something similar in FreeBSD (which has an independent reimplementation of zstd's build). (Something similar could be done for Cmake build, which does not appear to set visibility symbols at all. I assume BUCK build does not care for dynamically-linked zstd and we can leave it alone.) |
@cemeyer I tried your patch on top of zstd 1.4.5 (had to adapt a little because meanwhile the makefiles changed a bit).
With my patch I don't have this problem, although I couldn't immediately find out how to fix it while keeping true to your method. |
The patch built on 1.4.8 because the intended symbol visibility was not being applied correctly. I don’t know if it was working in 1.4.5. It was fixed again in dev by #2441 . Dev branch has a way to build dll-linked cli now, I would just use that instead. |
Great, the 'zstd-dll' target does match what I need. Looking forward to the next release... |
This matches the Makefile build. Due to one private xxhash symbol in use by the program, it recompiles a private copy of xxhash. Ref. facebook#2261
The linked PR fixes symbol visibility for meson. |
This matches the Makefile build. Due to one private xxhash symbol in use by the program, it recompiles a private copy of xxhash. Ref. facebook#2261
This matches the Makefile build. Due to one private xxhash symbol in use by the program, it recompiles a private copy of xxhash. Due to the test binaries making extensive (?) use of private symbols, it doesn't even attempt to link to shared libzstd, and instead, all of the original object files are added to libtestcommon itself for private linkage. This, too, matches the Makefile build. Ref. facebook#2261
This matches the Makefile build. Due to one private xxhash symbol in use by the program, it recompiles a private copy of xxhash. Due to the test binaries making extensive (?) use of private symbols, it doesn't even attempt to link to shared libzstd, and instead, all of the original object files are added to libtestcommon itself for private linkage. This, too, matches the Makefile build. Ref. facebook#2261
This matches the Makefile build. Due to one private xxhash symbol in use by the program, it recompiles a private copy of xxhash. Due to the test binaries making extensive (?) use of private symbols, it doesn't even attempt to link to shared libzstd, and instead, all of the original object files are added to libtestcommon itself for private linkage. This, too, matches the Makefile build. Ref. facebook#2261
Describe the bug
The compiler and link commands used depend on the build system used, e.g. make vs cmake (maybe same for the other build systems). This is unexpected and undesired.
For example, for libzstd, the makefile specifies -fvisibility=hidden, whereas the cmake version does not.
Similarly, the compilation of the 'programs' have many compiler warning flags which are absent for cmake.
On the other hand, the cmake system now allows to link the 'zstd' program dynamically to libzstd via -DZSTD_PROGRAMS_LINK_SHARED=ON, but this feature is not supported in the 'make' system. There does exist a 'zstd-dll' target, which does not work because the visibility of symbols in libzstd is set to hidden.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expect the same output files regardless of the build system
Additional context
With the upgrade from zstd 1.4.3 to 1.4.5, I notice yet another big increase in size, +500KB on libzstd. I thus wanted to benefit from ZSTD_PROGRAMS_LINK_SHARED=ON, but zstd as packaged in Buildroot is using 'make', hence I stumbled upon these inconsistencies.
The text was updated successfully, but these errors were encountered: