Add option to build with dynamic libc and c++, but static other dependencies; change static option name #4597
Conversation
vlstill
added
enhancement
|
I've also added a CI job for this option. I'm not sure if we want it running all the time, but unless we are quite constrained by the amount of CI runner hours we can use I suggest we keep it. |
I would make it nightly or optional. We are indeed quite constrained on CI hours these days. |
In that case I suggest making both static variants nightly with option to enable them by a label (probably one label for both), similar to validate or sanitizers. @fruffy If you agree, please disable the "required" on the |
Sounds like a good idea. I think one label is good enough. I will disable the required once this PR is ready to be merged. |
CMakeLists.txt
Outdated
| "Build a (mostly) statically linked release binary. Glibc is linked dynamically." OFF | ||
| ) | ||
| if (BUILD_STATIC_RELEASE_SANS_GLIBC) | ||
| OPTION (BUILD_STATIC_RELEASE_SANS_GLIBC "Build a (mostly) statically linked release binary. Glibc \ |
There was a problem hiding this comment.
It might make sense to drop the sans and just use "dynamic". It's a little longer but gets the point across better?
There was a problem hiding this comment.
what about BUILD_PREFER_STATIC_DYNAMIC_GLIBC/...DYNAMIC_STDLIB? That I think is better aligned with the meaning. "...WITH_DYNAMIC..." would read even better, but the option is quite long already :-/.
Do we want a "deprecated" catch for the old spelling? Or do we expect the downstreams to notice/have tests in place :-). I have no idea who uses this besides the Altera compiler :-D.
There was a problem hiding this comment.
Yeah let's just drop it, iirc the Tofino compiler also had its own static build.
There was a problem hiding this comment.
I know we are bikeshedding here but I feel like STATIC_BUILD_PREFER_DYNAMIC_GLIBC is easier to read?
There was a problem hiding this comment.
I think the thing that is preferred is the static, except for glibc/stdlib. Or we could just drop the PREFER and name this BUILD_STATIC_WITH_DYNAMIC_GLIBC, or even STATIC_BUILD_WITH_DYNAMIC_GLIBC (I feel like the BUILD is a prefix for build options, e.g. also BUILD_LINK_WITH_GOLD etc., but I don't have too strong feelings about this).
There was a problem hiding this comment.
Well since I got confused about it it looks like it is a little too ambiguous, STATIC_BUILD_WITH_DYNAMIC_GLIBC is probably the most straightforward?
There was a problem hiding this comment.
OK. I've renamed it.
vlstill
force-pushed
the
sans-stdlib
branch
2 times, most recently
from
2922ce8 to
097316c
Compare
…ther dependencies
…pt, run on schedule + optional
vlstill
changed the title
|
@fruffy, did you already remove the static check from the required once? I'm little surprised I don't see it as missing since it was renamed. |
Yes I did |
Breaking change: CMake option
BUILD_STATIC_SANS_GLIBCwas renamed toSTATIC_BUILD_WITH_DYNAMIC_GLIBC.The semi-static build that we support now (
BUILD_STATIC_SANS_GLIBC) is useful for building binaries that can be redistributed without adding runtime dependencies on dynamic libraries. However, it is only applicable if all the C++-std-library-using dependencies can be linked statically. If a downstream project has some C++ dependencies (that use the standard library) that need to be linked dynamically this leads to inconsistencies in libstd++ initialization which can render the library unusable.One can of course fall back to fully-dynamic build, but in my opinion it is useful to be able to link dependencies such as Boost, Abseil and Z3 statically even if there are some dependencies that need to be linked dynamically.
This PR introduces a new build option
BUILD_STATIC_WITH_DYNAMIC_STDLIBthat links all the libraries it can find statically, but the libc and libstdc++ (or other C++ stdlib) are linked dynamically.