[PATCH] tests/meson: fix mock library link on MacOS

Daniel Henrique Barboza danielhb413 at gmail.com
Mon Aug 31 14:35:59 UTC 2020



On 8/31/20 11:19 AM, Ján Tomko wrote:
> On a Monday in 2020, Michal Privoznik wrote:
>> On 8/31/20 3:36 PM, Daniel Henrique Barboza wrote:
>>>
>>>
>>> On 8/28/20 4:35 PM, Scott Shambarger wrote:
>>>> MacOS can not pre-load modules, so mock libraries must be built
>>>> as shared libraries (without asneeded striping, and undefined
>>>> symbols allowed).
>>>>
>>>> Signed-off-by: Scott Shambarger <scott-libvirt at shambarger.net>
>>>> ---
>>>
>>> Given that this is a MacOS specific limitation it's not a good idea
>>> to force it on the common code for everyone else.
>>>
>>> The 'meson.build' file in the project root uses, in line 1727:
>>>
>>> host_machine.system() != 'darwin'
>>>
>>> To identify the building system as MacOS. IMO you should use an
>>> "if host_machine.system() != 'darwin'" inside the 'foreach' loop
>>> below to do whatever it is necessary for MacOS, leave the rest as
>>> is.
> 
> I don't see a problem with "forcing" this on non-MacOS.
> The `-Wl,--no-undefined` option seems to be implied by the wording of `shared_module`:
> 
>      This is useful for building modules that will be dlopen()ed and
>      hence may contain undefined symbols that will be provided by the
>      library that is loading it.
> 
> And `-Wl,--as-needed` sounds harmless enough (and the test suite passes
> for me)
> 
> https://mesonbuild.com/Reference-manual.html#shared_library

If it's benign/non-detrimental to other OSes then it's fine by me. It doesn't
break the test suite for me either, and based on what you said, it shouldn't
be much of a problem for other setups.


Thanks,


DHB


> 
>>>
>>
>> Thing is, we want our test suite to run on as many platforms as possible (ideally every supported one), because only then we can guarantee basic functionality of that platform. But client also contains some drivers and thus is worth testing. Therefore, I would rather see us running all tests possible.
>>
> 
> How is that related to this patch?
> 
> Jano
> 
>> Michal
>>




More information about the libvir-list mailing list