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

CMake module not automatically setting build and MSVC runtime type #8046

Open
CoffeeFlux opened this issue Nov 28, 2020 · 2 comments
Open

CMake module not automatically setting build and MSVC runtime type #8046

CoffeeFlux opened this issue Nov 28, 2020 · 2 comments
Labels
enhancement module:cmake Issues related to the cmake module, including cmake.subproject subprojects/wraps

Comments

@CoffeeFlux
Copy link
Contributor

CoffeeFlux commented Nov 28, 2020

When building cURL as a CMake subproject on Windows with MSVC, I was running into linker errors with the VC runtime. It appears the larger Meson project's settings regarding the build type and b_vscrt are not passed down, so if the CMake subproject builds debug by default and the higher-level project is release or debugoptimized, you will be trying to link against two different versions of the runtime.

In my case, I can solve this by just setting MSVC_RUNTIME_LIBRARY or CMAKE_BUILD_TYPE (which will then default to the optimized runtime). I opted for the latter and now it links correctly, but I wanted to see if not propagating this is intentional or not. If it is, it might be worth mentioning this in the documentation, as I would not have guessed that it would be a problem.

Meson version: 0.56.0
CMake version: 3.19.0

How I'm invoking the CMake module: https://github.com/TypesettingTools/ffi-experiments/blob/3b9efd7a8b4e93386e0bcbe84acf33a7a9ef8615/meson.build#L16-L41

@mensinda mensinda added dependency:cmake Issues related to `dependency` with the `cmake` method enhancement subprojects/wraps labels Nov 28, 2020
@mensinda
Copy link
Member

Doing this internally should be possible.

In the meantime, setting either of the two CMake variables (preferably in a cross or native file using the new [cmake] section) would be the way to go.

@dcbaker dcbaker added module:cmake Issues related to the cmake module, including cmake.subproject and removed dependency:cmake Issues related to `dependency` with the `cmake` method labels Jun 28, 2022
@szanni
Copy link
Contributor

szanni commented Nov 21, 2022

Confirmed. The issue still presents itself for:

  • meson 0.64.0
  • cmake 3.24.0

I would consider this to be a bug though, not an enhancement.

Linking fails miserably otherwise and the error message is sadly not terribly helpful.

The other setting that does not get passed down is b_staticpic. Happy to open another issue (probably one already exists).

The following did the trick for me, the project I am using does not have a well formed CMakeList.txt like curl:

cmake = import('cmake')
cmake_opts = cmake.subproject_options()
cmake_opts.add_cmake_defines({
  'CMAKE_POSITION_INDEPENDENT_CODE': true,
  'CMAKE_MSVC_RUNTIME_LIBRARY': 'MultiThreaded',
  'CMAKE_BUILD_TYPE': 'Release'
})

mylib_proj = cmake.subproject('mylib', options : cmake_opts)
mylib_dep = libsamplerate_proj.dependency('mylib')

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement module:cmake Issues related to the cmake module, including cmake.subproject subprojects/wraps
Projects
None yet
Development

No branches or pull requests

4 participants