Meson build on macOS: undefined symbol treatment

Meson build on macOS: undefined symbol treatment

[Emmanuel Blot]

Hi,

I’ve noticed that since meson builds have been enabled, on macOS, the 
build outcome with undefined symbols has changed:

- prior to meson introduction (v5.1.0):
   * referencing an undeclared symbol in source code led to a warning at 
compile stage
   * referencing an undeclared symbol at link stage led to a fatal build 
error (as usually expected)

- since meson introduction
   * same behavior at compile stage
   * however, the linker does silently generate an application - which 
fails at launch since the symbol is undefined.

Step to reproduce:

   from softmmu/main.c, replace for example call to qemu_init() with 
qemu_init2();

- v5.1.0:
   softmmu/main.c:48:5: warning: implicit declaration of function 
'qemu_init2' is invalid in C99 [-Wimplicit-function-declaration]
     qemu_init2(argc, argv, envp);
       LINK    riscv64-softmmu/qemu-system-riscv64
   Undefined symbols for architecture x86_64:
     "_qemu_init2", referenced from:
         _qemu_main in main.o
   ld: symbol(s) not found for architecture x86_64
   clang: error: linker command failed with exit code 1 (use -v to see 
invocation)
   make[1]: *** [qemu-system-riscv64] Error 1

- current master:
   softmmu/main.c:49:5: warning: implicit declaration of function 
'qemu_init2' is invalid in C99 [-Wimplicit-function-declaration]
     qemu_init2(argc, argv, envp);
     ^
   1 warning generated.
   [3/3] Linking target qemu-system-riscv64

  > riscv64-softmmu/qemu-system-riscv64
   dyld: lazy symbol binding failed: Symbol not found: _qemu_init2
     Referenced from: 
/Users/eblot/Sources/Git/github.com/QEMU/upstream/build/riscv64-softmmu/qemu-system-riscv64
     Expected in: flat namespace

     'riscv64-softmmu/qemu-system-ris…' terminated by signal SIGABRT 
(Abort)


This new behavior is likely to come from the linker flag:

    -Wl,-undefined,dynamic_lookup

I’m not sure whether it is a new feature or a bug, but if the former 
stands true, is there a way to disable this feature?


Thanks,
Emmanuel.

Re: Meson build on macOS: undefined symbol treatment

[Thomas Huth]

On 26/08/2020 15.11, Emmanuel Blot wrote:
> Hi,
> 
> I’ve noticed that since meson builds have been enabled, on macOS, the
> build outcome with undefined symbols has changed:
> 
> - prior to meson introduction (v5.1.0):
>   * referencing an undeclared symbol in source code led to a warning at
> compile stage
>   * referencing an undeclared symbol at link stage led to a fatal build
> error (as usually expected)
> 
> - since meson introduction
>   * same behavior at compile stage
>   * however, the linker does silently generate an application - which
> fails at launch since the symbol is undefined.
> 
> Step to reproduce:
> 
>   from softmmu/main.c, replace for example call to qemu_init() with
> qemu_init2();
> 
> - v5.1.0:
>   softmmu/main.c:48:5: warning: implicit declaration of function
> 'qemu_init2' is invalid in C99 [-Wimplicit-function-declaration]
>     qemu_init2(argc, argv, envp);
>       LINK    riscv64-softmmu/qemu-system-riscv64
>   Undefined symbols for architecture x86_64:
>     "_qemu_init2", referenced from:
>         _qemu_main in main.o
>   ld: symbol(s) not found for architecture x86_64
>   clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>   make[1]: *** [qemu-system-riscv64] Error 1
> 
> - current master:
>   softmmu/main.c:49:5: warning: implicit declaration of function
> 'qemu_init2' is invalid in C99 [-Wimplicit-function-declaration]
>     qemu_init2(argc, argv, envp);
>     ^
>   1 warning generated.
>   [3/3] Linking target qemu-system-riscv64
> 
>  > riscv64-softmmu/qemu-system-riscv64
>   dyld: lazy symbol binding failed: Symbol not found: _qemu_init2
>     Referenced from:
> /Users/eblot/Sources/Git/github.com/QEMU/upstream/build/riscv64-softmmu/qemu-system-riscv64
> 
>     Expected in: flat namespace
> 
>     'riscv64-softmmu/qemu-system-ris…' terminated by signal SIGABRT (Abort)
> 
> 
> This new behavior is likely to come from the linker flag:
> 
>    -Wl,-undefined,dynamic_lookup
> 
> I’m not sure whether it is a new feature or a bug, but if the former
> stands true, is there a way to disable this feature?

Seems like this is added by meson itself (see
meson/mesonbuild/linkers.py), not by our meson.build files ... Paolo,
any idea why this happens?

 Thomas

Re: Meson build on macOS: undefined symbol treatment

[Paolo Bonzini]

On 27/08/20 10:16, Thomas Huth wrote:
> Seems like this is added by meson itself (see
> meson/mesonbuild/linkers.py), not by our meson.build files ... Paolo,
> any idea why this happens?

This is done by "b_lundef=false".  I think it was added for modules, but
maybe it's not necessary.  Emmanuel, can you try removing it (line 3 of
meson.build) and seeing if --enable-modules still works for you?

Paolo

Re: Meson build on macOS: undefined symbol treatment

[Emmanuel Blot]

On 30 Aug 2020, at 11:35, Paolo Bonzini wrote:

> This is done by "b_lundef=false".  I think it was added for modules, 
> but
> maybe it's not necessary.  Emmanuel, can you try removing it (line 3 
> of
> meson.build) and seeing if --enable-modules still works for you?

Removing this option does restore the regular behavior on macOS (link 
stage fails whenever some symbols are missing), and QEMU still builds ok 
with —enable-modules option, but I have not actually tested this 
feature - I did not know it even existed. Do you want me to test some 
specific use cases?

Thanks,
Emmanuel.

Re: Meson build on macOS: undefined symbol treatment

[Paolo Bonzini]

On 31/08/20 10:12, Emmanuel Blot wrote:
> 
>> This is done by "b_lundef=false".  I think it was added for modules, but
>> maybe it's not necessary.  Emmanuel, can you try removing it (line 3 of
>> meson.build) and seeing if --enable-modules still works for you?
> 
> Removing this option does restore the regular behavior on macOS (link
> stage fails whenever some symbols are missing), and QEMU still builds ok
> with --enable-modules option, but I have not actually tested this feature
> - I did not know it even existed. Do you want me to test some specific
> use cases?

That's good enough for now, thanks!

Paolo