dotnet
version 20.1.2 broken again on linux (workaround for stddef.h issue not working anymore)
stddef.h is not found since upgrading to 20.1.2
Glfw failed with 1 error(s) (0.5s)
Diagnostics for 'Include/GLFW/glfw3.h':
Include/GLFW/glfw3.h:103:10: fatal error: 'stddef.h' file not found
Skipping 'Include/GLFW/glfw3.h' due to one or more errors listed above.
before building RT_LIBRARY_PATH is set so dependencies on the native libraries are met.
export LD_LIBRARY_PATH=[PATH_TO_PROJECT]/Build/linux && ClangSharpPInvokeGenerator -o Bindings.cs -x c -c generate-macro-bindings -c latest-codegen -r char=byte -n Glfw -l Libs/glfw3 -I ../Vulkan/Include -D GLFW_INCLUDE_NONE -D GLFW_INCLUDE_VULKAN -f Include/GLFW/glfw3.h
ldd reports the shared libraries being found:
ldd ../../../Build/linux/*
../../../Build/linux/libClangSharp.so:
linux-vdso.so.1 (0x0000715ad8f9e000)
libclang.so.20.1 => [PATH_TO_PROJECT]/Build/linux/libclang.so.20.1 (0x0000715acbc00000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x0000715ad8f7d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x0000715ad8f78000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x0000715acb800000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000715ad8e81000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000715ad8e52000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000715acb400000)
/lib64/ld-linux-x86-64.so.2 (0x0000715ad8fa0000)
../../../Build/linux/libclang.so:
linux-vdso.so.1 (0x0000789d1413c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x0000789d1411b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x0000789d14116000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000789d1401f000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000789d13ff2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000789d0aa00000)
/lib64/ld-linux-x86-64.so.2 (0x0000789d1413e000)
../../../Build/linux/libclang.so.20:
linux-vdso.so.1 (0x00007a8ddc022000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007a8ddc001000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007a8ddbffc000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007a8dd2d09000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007a8ddbfcf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007a8dd2a00000)
/lib64/ld-linux-x86-64.so.2 (0x00007a8ddc024000)
../../../Build/linux/libclang.so.20.1:
linux-vdso.so.1 (0x000073f7ed0c5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x000073f7ed0a4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x000073f7ed09f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000073f7ecfa8000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000073f7ecf7b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000073f7e3a00000)
/lib64/ld-linux-x86-64.so.2 (0x000073f7ed0c7000)
(libclang.so.20 and libclang.so are symlinks to libclang.so.20.1 since libClangSharp.so only loads the exact path with version and the c# code tries to load libclang.so without the full version)
this workaround used to work on previous versions on this tool but not anymore.
Turns out that the system libclang is not packaged as libclang.so anymore. the only binary installed by the package mangaer are:
libclang-20.so.20 (libc6,x86-64) => /lib/x86_64-linux-gnu/libclang-20.so.20
libclang-20.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libclang-20.so
so Build/linux$ ln -s /lib/x86_64-linux-gnu/libclang-20.so libclang.so does fix this issue but its very hacky and the maintainer should really get on top of what is happening here.
building is still broken due to a seperate bug added somewhere after 18.1.0
does fix this issue but its very hacky and the maintainer should really get on top of what is happening here.
Looks like the issue is that the resolution path missed getting updated to check for libclang-20: https://github.com/dotnet/ClangSharp/blob/main/sources/ClangSharp.Interop/clang.cs#L40-L51
This is also notably just a general pain point because every Linux distro does its own thing, there isn't a consistency like exists for Windows or MacOS. The tooling generally tries to handle things but if you're on Linux you may end up having to do extra.
stddef.h is not found since upgrading to 20.1.2
Nothing with regards to ClangSharp changed here and all tests, including downstream projects that use ClangSharp for binding generation on Linux, MacOS, and Windows are working. If anything changed, it would be on the libClang side of things and you'd likely find the same break if you used clang.exe directly.
In general, it is best practice to explicitly pass in system include paths; just as tools like Make or CMake will do.
