Exclusion of static libs for static runtime usage
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- cmake
- Domain
- build-system
Research direction
Reproduce the default ./b2 install layout on Linux and inspect the CMake configuration logic shown for chrono, especially the Boost_USE_STATIC_RUNTIME check. Compare system and tagged layouts with static and shared runtime builds, then verify whether allowing the static library for both runtime choices works without breaking the platform-specific behavior noted in the issue.
Written by the indexing model from the issue text.
Description
If I do a build with default settings (e.g. just ./b2 install) on linux, I get dynamic and static libs built using the system naming convention. By default, boost assumes a shared runtime. For static libs, however, does it really matter? For instance, my consuming application specifies both Boost_USE_STATIC_LIBS and Boost_USE_STATIC_RUNTIME and thus the default install fails to find the library because of this cmake config code (just using chrono as an example here) :
# runtime-link=shared
if(Boost_USE_STATIC_RUNTIME)
_BOOST_SKIPPED("libboost_chrono.a" "shared runtime, Boost_USE_STATIC_RUNTIME=${Boost_USE_STATIC_RUNTIME}")
return()
endif()
When I switch to a tagged layout and build versions for both static and shared runtime, I get two copies of what appear to be the same static library. Couldn't we just make an exception and allow the system layout to work for either runtime choice? I realize this might be OS dependent since windows is clearly different in this regard and apple-clang doesn't allow static runtime at all (I believe).
- Dominant language
- C
- Stars
- 11
- Forks
- 37
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from boostorg/boost_install
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
boostorg/boost_install#82 · 9 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
boostorg/boost_install#79 · 11 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 48/100
boostorg/boost_install#76 · 3 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
boostorg/boost_install#67 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
boostorg/boost_install#66 · 6 comments ·
All issues in boostorg/boost_install
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
level/task module/gcp type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
Difficulty 1/5 Under an hour Newbie friendliness 86/100
hapostgres/pg_auto_failover#1190 ·
-
docs
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
P3 sonic-vpp
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
sonic-net/sonic-buildimage#29662 ·