Cannot link to built Vala shared library when using MSVC

[Prince781]

Describe the bug
Linking with a Vala shared library fails when using MSVC on Windows. The problem I think is that the import library for the dll isn't generated. Positional arguments like implib or export_dynamic aren't supported with *library(), but I think this should be done automatically. link gives an error like cannot open input file lib\valalib.lib

[1/1] Linking target prog/valaprog.exe
FAILED: prog/valaprog.exe prog/valaprog.pdb
"link"  /MACHINE:x64 /OUT:prog/valaprog.exe prog/valaprog.exe.p/meson-generated_prog.c.obj "/nologo" "/release" "/nologo" "/DEBUG" "/PDB:prog\valaprog.pdb" "lib\valalib.lib" "C:/lib/glib-2.0.lib" "C:/lib/intl.lib" "/LIBPATH:C://lib" "ws2_32.lib" "winmm.lib" "C:/lib/gobject-2.0.lib" "C:/lib/ffi.lib" "/LIBPATH:C://lib" "ws2_32.lib" "winmm.lib" "/SUBSYSTEM:CONSOLE" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib"
LINK : fatal error LNK1181: cannot open input file 'lib\valalib.lib'
ninja: build stopped: subcommand failed.

To Reproduce
Just run test case vala\7 shared library on Windows using cl for C compiler and link for linker.

Expected behavior
Linking with a Vala built shared library should work.

system parameters

• this is not a cross build
• OS: Windows 10
• Python 3.9.4
• Meson 0.57.2
• Ninja 1.10.2
• cl.exe msvc 19.29.30031 "Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30031 for x64"
• link.exe14.29.30031.0

[Prince781]

I think the issue here might be more general: Meson has no way to ensure that an import library is generated for a .dll. On Windows you have to declare your symbols to export from a library with __declspec(dllexport) or in a module definition file, otherwise by default nothing is exported and no import library is generated, even if you use the /IMPLIB flag:

LINK ignores /IMPLIB when an import library is not being created. If no exports are specified, LINK does not create an import library.

On Linux, GCC and Clang export library symbols by default and you link directly to the .so, so this isn't a problem. I'm actually seeing this issue with C on Windows too, so it's not just a Vala problem.

It seems that CMake has a way to address this problem with the WINDOWS_EXPORT_ALL_SYMBOLS property.

Some more useful links:

• https://blog.kitware.com/create-dlls-on-windows-without-declspec-using-new-cmake-export-all-feature/
• https://stackoverflow.com/questions/225432/export-all-symbols-when-creating-a-dll

[Prince781]

So the problem here is either:

• valac should generate library symbols prefixed with something like VALA_EXPORT that evaluates to __declspec(dllexport) on MSVC and empty otherwise
• Meson should include a feature like what CMake has to automatically export all public symbols in a .dll when compiling with MSVC, to match the behavior of GCC and Clang.

[tp-m]

You can also provide a .def file with the symbols you want exported if you don't want to do the dllexport thing.

[Prince781]

You can also provide a .def file with the symbols you want exported if you don't want to do the dllexport thing.

Sure, but that would have to be auto-generated.

[tp-m]

Just saying that this doesn't look vala-specific at all, it's the same with C.

[tp-m]

Basically a duplicate of #2132 I think.

[Prince781]

@tp-m yes, you're probably right. Had I seen that before making this issue I might've decided to just mention there how this breaks Vala builds as well.

[dcbaker]

This really feels like a valac bug issue to me, valac should be able to correclty annotate the functions automatically, not rely on build system hacks or for users to be able to guess the generated symbol names and write their own .def files.

[Prince781]

https://gitlab.gnome.org/GNOME/vala/-/merge_requests/178

closing