Overlapping include-paths in a wrapped dependency

[lhearachel]

Reproducible example: https://github.com/lhearachel/rapidyaml-meson

For one of my maintained projects, I'm writing a Meson patch for biojppm/rapidyaml, which uses cmake as its primary build-chain. I have written up the following minimal meson.build file as a patch to apply to a wrapped subproject (all paths replaced with wildcards for brevity only):

project(
  'ryml',
  'cpp',
  version: '0.7.2',
  default_options: ['default_library=static'],
)

c4core_hpps = files(
  'ext/c4core/src/c4/*.hpp',
)

c4core_cpps = files(
  'ext/c4core/src/c4/*.cpp',
)

ryml_hpps = files(
  'src/c4/yml/*.hpp',
  'src/ryml.hpp',
  'src/ryml_std.hpp',
)

ryml_cpps = files(
  'src/c4/yml/*.cpp',
)

c4core_includes = include_directories('ext/c4core/src')
ryml_includes = include_directories('src')

libc4core = library(
  'c4core',
  sources: [c4core_hpps, c4core_cpps],
  include_directories: [c4core_includes],
  native: true,
  install: not meson.is_cross_build(),
)
libc4core_dep = declare_dependency(
  sources: [c4core_hpps],
  include_directories: [c4core_includes],
  link_with: [
    libc4core,
  ],
)

libryml = library(
  'ryml',
  sources: [ryml_hpps, ryml_cpps],
  include_directories: [c4core_includes, ryml_includes],
  link_with: [libc4core],
  native: true,
  install: not meson.is_cross_build(),
  dependencies: [
    libc4core_dep,
  ],
)
libryml_dep = declare_dependency(
  sources: [ryml_hpps, c4core_hpps],
  include_directories: [ryml_includes],
  link_with: [
    libryml,
  ],
  dependencies: [
    libc4core_dep,
  ],
)

meson.override_dependency('libryml', libryml_dep)
meson.override_dependency('libc4core', libc4core_dep)

I also have the following executable target:

subproject('rapidyaml')

libc4core_dep = dependency('libc4core')
libryml_dep = dependency('libryml')

datagen_exe = executable(
  'datagen',
  sources: files('datagen.cpp'),
  cpp_args: ['-std=c++17'],
  implicit_include_directories: true,
  include_directories: toplevel_includes, # Set in my root `meson.build` as `include_directories('.')`
  dependencies: [
    libc4core_dep,
    libryml_dep,
  ],
  native: true,
)

However, when I attempt to build this executable, ld claims that it cannot find the definition for a function from within the library:

/usr/bin/ld: tools/datagen/datagen.p/datagen.cpp.o: in function `main':
datagen.cpp:(.text+0xb404): undefined reference to `c4::to_csubstr(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'

Notably, this function should be in the lower of the two libraries (c4core, which ryml has a dependency on). Some basic introspection with the LSP (as useful as that might be) suggests that headers from c4core are not being included in the possible include paths, but my understanding of dep objects is that they carry include directories along with them, as well as what libraries need to be linked against. Further, the code should be failing to compile into an object at all if the header could not be found.

I did some sanity-checking, as well, to verify that the libraries are actually being built:

> ll build/subproejcts/rapidyaml-0.7.2-src/
.rwxr-xr-x  52k rachel 13 Jan 17:53 libc4core.so
drwxr-xr-x    - rachel 13 Jan 17:53 libc4core.so.p
.rwxr-xr-x 1.1M rachel 13 Jan 17:53 libryml.so
drwxr-xr-x    - rachel 13 Jan 17:53 libryml.so.p

Am I missing something elementary?

[eli-schwartz]

Notably, this function should be in the lower of the two libraries (c4core, which ryml has a dependency on). Some basic introspection with the LSP (as useful as that might be) suggests that headers from c4core are not being included in the possible include paths, but my understanding of dep objects is that they carry include directories along with them, as well as what libraries need to be linked against. Further, the code should be failing to compile into an object at all if the header could not be found.

The error message comes from ld, not the compiler, which indicates that the symbol is not available when running nm -D on the shared libraries in the link command. Therefore ld was unable to bind to the shared library correctly.

Headers aren't involved here.

...

If the meson wrap is publicly available then it might be helpful for us to be able to test it live and see what may be going wrong.

[lhearachel]

If the meson wrap is publicly available then it might be helpful for us to be able to test it live and see what may be going wrong.

I've added a link to the description for a small Github repo that reproduces the issue on my machine.