Re: [RFC PATCH v3 2/5] rust: add bindgen step as a meson dependency

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

On 7/2/24 05:25, Manos Pitsidianakis wrote:
> On Mon, 01 Jul 2024 21:54, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>> The ctor is not run, but, interesting point, there is the same problem
>> on Linux :)
>>
>> Can you please confirm with a clean build this work on your machine with
>> this v3, and report exact configure and run commands you use?
> 
> On a clean checkout, I did exactly the following:
> 
> ```
> mkdir ./build && cd ./build
> ../configure --enable-system --enable-debug \
>   --target-list=aarch64-softmmu --enable-with-rust
> ninja qemu-system-aarch64
> ```
> 

Debug flag was the difference.
After looking with Manos, we identified an issue with release builds 
(unused symbols gets dropped, including device ctor), that will be 
solved in v4.

> which selected the default cc/gcc on debian,
> gcc (Debian 12.2.0-14) 12.2.0
> 
> and ran QEMU with like this:
> 
> ```
> ./qemu-system-aarch64 -M virt \
>    -machine virtualization=true -machine virt,gic-version=3 \
>    -cpu max,pauth-impdef=on -smp 2 -m 4096 \
>    [.. drive and img arguments ..] \
>    -nographic
> ```
> 
> 
>>
>> Thanks,
>> Pierrick
>>
>> On 6/29/24 01:06, Manos Pitsidianakis wrote:
>>> On Fri, 28 Jun 2024 22:12, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
>>>> I've been able to build rust device on windows, with a few tweaks
>>>> needed.
>>>>
>>>> - specificy the target for libclang (used by bindgen), which targets
>>>> MSVC by default (so different set of headers)
>>>> - additional headers (libclang searches its own header with a relative
>>>> path instead of absolute)
>>>> - additional windows libs that must be linked in final executable
>>>>
>>>> However, even tough I can build the executable, I get this error:
>>>> $ ./build/qemu-system-aarch64 -M virt
>>>> C:\w\qemu\build\qemu-system-aarch64.exe: unknown type 'x-pl011-rust'
>>>>
>>>> Any idea of what could be missing here?
>>>
>>> Sounds like either the rust lib is not linked to the final binary (which
>>> you can confirm if you look at the included symbols and don't see
>>> anything with rust origin) or the constructor decorated with
>>> #[cfg_attr(target_os = "windows", link_section = ".CRT$XCU"] is not
>>> linked properly (you can add a puts() and see if it's invoked or add a
>>> breakpoint in gdb)