On Tue, Feb 04, 2020 at 03:27:50PM +0100, Thomas Monjalon wrote:
> 04/02/2020 12:48, Bruce Richardson:
> > as we discussed offline, I really don't like the necessity of the
> > hidden_deps part of this, so I've tried coming up with some other
> > solutions.
>
> Thanks for looking closely at these patches.
>
> > For example, in my testing I get the same result with the
> > following diff instead of the second two patches (just showing for mlx5 -
> > changes for mlx4 are identical):
> [...]
> > - # Build without adding shared libs to
> > Requires.private
> > - hidden_deps +=
> > lib.partial_dependency(compile_args:true)
> [...]
> > + ibv_cflags = run_command(find_program('pkg-config'), '--cflags',
> > 'libibverbs').stdout()
> [...]
> > By doing things this way - assuming it works in your tests too - we avoid
> > any need to change anything in the common drivers code.
>
> Yes, you hide the dependency by getting cflags directly with pkg-config.
> I wanted to avoid such solution because I was trying to use as much
> as possible the meson infrastructure.
>
> I think your solution relying on one more call to pkg-config is acceptable.
> I will test it and will review whether we get all corner cases.
>
Thanks.
It's not really ideal, but this is likely always going to be a bit flakey
since we can't use distro-supplied .a files, and your scripting is needed
to prevent even accidentally taking a non-custom-build rdma-core file.
Furthermore, I see that while meson tracks PKG_CONFIG_PATH value itself for
finding things, this does not get tracked between runs for shell calls.
This can catch one out, for example:
PKG_CONFIG_PATH=/path/to/pc/files meson build
will work correctly for everything. However, if one does a reconfigure
subsequently doing e.g. ninja reconfigure, meson will correctly pick up the
.pc files, but the ibverbs-static script, or any run_command calls to
pkg-config won't as it's not actually in the environment :-(
> In the meantime I discovered we are overlinking with meson
> when using the dlopen linking option.
> I will try to fix it as well with the same method.
>
Right. Overlinking is probably less serious an issue though. Does it cause
any real-world problems?
/Bruce
