Skip to content
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

Exclusion of static libs for static runtime usage #8

Open
mellery451 opened this issue May 22, 2019 · 3 comments
Open

Exclusion of static libs for static runtime usage #8

mellery451 opened this issue May 22, 2019 · 3 comments

Comments

@mellery451
Copy link

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).

@pdimov pdimov transferred this issue from boostorg/mincmake May 22, 2019
@pdimov
Copy link
Member

pdimov commented May 22, 2019

We could hack around this in principle but it seems to me that setting Boost_USE_STATIC_RUNTIME is correct to reject libraries built with the shared runtime. Is the mistake not in the consuming app, which should only request static runtime when it means it, guarded by if(WIN32)?

@mellery451
Copy link
Author

ok - that's an interesting point. I could see the argument for pushing this on to the consuming side I guess.

@Flamefire
Copy link

I agree with @pdimov after checking e.g. FindBoost.

Examples:

# Example to find Boost headers and some *static* libraries::
#
#   set(Boost_USE_STATIC_LIBS        ON) # only find static libs
#   set(Boost_USE_MULTITHREADED      ON)
#   set(Boost_USE_STATIC_RUNTIME    OFF)

To disable the ambiguous behavior, the user need only
set Boost_USE_STATIC_RUNTIME either ON or OFF.

Only real difference is on non-versioned layout in which you had shared and static libs of "unknown" properties and FindBoost would pick them anyway.

Question though: Where does static_runtime actually has an effect? Could it be disabled for cases where it really has no effect?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants