build-llvm: Install and keep llvm-lib

[robUx4]

It's an equivalent to MSVC lib.exe.

It is used by meson to find the DLL name from a .lib/.dll.a. The other option is dlltool, which is not the same as llvm-dlltool.

[mstorsjo]

Looks reasonable, thanks!

It is used by meson to find the DLL name from a .lib/.dll.a.

Can you explain in which use case with meson it tries to use this?

The other option is dlltool, which is not the same as llvm-dlltool.

I presume you mean that meson could try to use dlltool, but llvm-dlltool doesn't implement the option that meson tries to use (-I)? We possibly should look into adding support for that too.

FWIW, the Meson use of (llvm-)lib -list to look at member names in an import library, to deduce the actual DLL name, seems a bit dangerous - if the import library is one generated by GNU tools (e.g. if building with GNU tools, but llvm-lib happens to be available in PATH), it would find a name like d012345.o, not mylib.dll.

[robUx4]

Can you explain in which use case with meson it tries to use this?

The context is https://code.videolan.org/videolan/vlc/-/merge_requests/6696#note_470495. meson relies on a symbol file to decide if files that depend on another DLL need to be relinked or not. That's fine except for cross-compilation they just go the dirty way and assume symbols are changed at any compilation of the DLL. With 400+ DLL dependent on the core in VLC, that's a lot of relinking for nothing.

I presume you mean that meson could try to use dlltool, but llvm-dlltool doesn't implement the option that meson tries to use (-I)? We possibly should look into adding support for that too.

That would also be nice. And won't require a patch of meson.

[mstorsjo]

Can you explain in which use case with meson it tries to use this?

The context is https://code.videolan.org/videolan/vlc/-/merge_requests/6696#note_470495. meson relies on a symbol file to decide if files that depend on another DLL need to be relinked or not. That's fine except for cross-compilation they just go the dirty way and assume symbols are changed at any compilation of the DLL. With 400+ DLL dependent on the core in VLC, that's a lot of relinking for nothing.

Thanks, I see. When building dav1d for mingw as a DLL, I can find this file, and see that it's empty.

However I don't see it getting any contents when I provide llvm-lib either, and when I look at the command for generating the file, meson --internal symbolextractor /home/martin/code/dav1d/build-mingw-dll src/libdav1d.dll src/libdav1d.dll.a src/libdav1d.dll.p/libdav1d.dll.symbols --cross-host=windows, I don't see _get_implib_dllname getting called at all.

I presume you mean that meson could try to use dlltool, but llvm-dlltool doesn't implement the option that meson tries to use (-I)? We possibly should look into adding support for that too.

That would also be nice. And won't require a patch of meson.

Well it would still require Meson to try <triple>-dlltool in order to find the tools in a cross compile setup, or require the user to specify the dlltool tool name in a cross file.

[robUx4]

I don't see _get_implib_dllname getting called at all.

This patch is needed to actually generate the symbols when cross-compiling. That's regardless of which tool is used to generate this list of symbols.

Well it would still require Meson to try -dlltool in order to find the tools in a cross compile setup, or require the user to specify the dlltool tool name in a cross file.

In my llvm-mingw installation I do have llvm-dlltool in /opt/llvm-mingw-20240518-ucrt-ubuntu-20.04-x86_64/bin/llvm-dlltool. Maybe the -I option would work regardless of the architecture ?

[mstorsjo]

I don't see _get_implib_dllname getting called at all.

This patch is needed to actually generate the symbols when cross-compiling. That's regardless of which tool is used to generate this list of symbols.

Ah, I see, thanks. I'll try with that.

Well it would still require Meson to try -dlltool in order to find the tools in a cross compile setup, or require the user to specify the dlltool tool name in a cross file.

In my llvm-mingw installation I do have llvm-dlltool in /opt/llvm-mingw-20240518-ucrt-ubuntu-20.04-x86_64/bin/llvm-dlltool. Maybe the -I option would work regardless of the architecture ?

If the option would be implemented, then yes, it would work regardless of architecture. So Meson could check for both dlltool and llvm-dlltool, but that wouldn't help in a cross-GNU/binutils setup, where you'd only have e.g. x86_64-w64-mingw32-dlltool available.

[mstorsjo]

I don't see _get_implib_dllname getting called at all.

This patch is needed to actually generate the symbols when cross-compiling. That's regardless of which tool is used to generate this list of symbols.

Ah, I see, thanks. I'll try with that.

Yes, with that one I can reproduce the situation. Thanks!

[robUx4]

poke, is it OK to include this ?

[mstorsjo]

Yeah, let's merge this.

I haven't yet gotten to implementing this in llvm-dlltool even if I wanted to. Once that is in place, and if meson would look for either llvm-dlltool or <triple>-dlltool for this purpose, we probably could drop this - but until then, this should be harmless enough.