Trouble compiling on Fedora 35

[jgforbes]

I am stumped: There seems to be an issue with the library paths on Fedora 35. From /opt/DATA1/git/nvidia-libs/BUILD/nvidia-libs/build.32/meson-logs/meson-log.txt

Running test binary command: /opt/DATA1/git/nvidia-libs/BUILD/nvidia-libs/build.32/meson-private/sanitycheckc.exe C compiler for the build machine: ccache cc (gcc 11.2.1 "cc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9)") C linker for the build machine: cc ld.bfd 2.37-10 Build machine cpu family: x86_64 Build machine cpu: x86_64 Host machine cpu family: x86 Host machine cpu: i686 Target machine cpu family: x86 Target machine cpu: i686 Running compile: Working directory: /opt/DATA1/git/nvidia-libs/BUILD/nvidia-libs/build.32/meson-private/tmpknsg64hb Command line: winegcc /opt/DATA1/git/nvidia-libs/BUILD/nvidia-libs/build.32/meson-private/tmpknsg64hb/testfile.c -o /opt/DATA1/git/nvidia-libs/BUILD/nvidia-libs/build.32/meson-private/tmpknsg64hb/output.exe -m32 --no-gnu-unique -DWINESRC -DWINE_NO_LONG_TYPES -Wno-attributes -Wno-implicit-function-declaration -D_FILE_OFFSET_BITS=64 -O0 -Wl,--start-group -ldl -Wl,--end-group -Wl,--allow-shlib-undefined -mwindows

Code: int main(void) { return 0; }

Compiler stdout:

Compiler stderr: /usr/bin/ld: skipping incompatible /usr/lib64/libdl.so when searching for -ldl /usr/bin/ld: cannot find -lshell32 /usr/bin/ld: cannot find -lcomdlg32 /usr/bin/ld: cannot find -lgdi32 /usr/bin/ld: cannot find -ladvapi32 /usr/bin/ld: cannot find -luser32 /usr/bin/ld: cannot find -lwinecrt0 /usr/bin/ld: cannot find -lkernel32 /usr/bin/ld: cannot find -lntdll /usr/bin/ld: skipping incompatible /usr/lib64/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc collect2: error: ld returned 1 exit status winegcc: /usr/lib64/ccache/gcc failed

meson.build:5:0: ERROR: C shared or static library 'dl' not found

[SveSop]

I wonder if this could be related: https://github.com/renode/renode/issues/267#issuecomment-984420987

I would believe it is a oddity, as normally the distro should always provide a symlink from the .so -> .so.X (X being whatever ABI/version++).

Meson should find this "by itself" tho, so i dunno. I have not tested compiling on Fedora myself, so i cant really say much about that... but it should noe be ONLY this project that would have this issue? Ill look into it some more tonight 😄

[SveSop]

@jgforbes Sorry for taking a bit.. but i am not particularly familiar with build packages on fedora.. I did however make a docker image with the required packages, and after some fiddling i came up with the following to be able to compile without errors:

sudo dnf -y groupinstall "C Development Tools and Libraries"
sudo dnf install -y meson ninja-build glslang mingw-w64-tools glibc-devel.* mingw64-gcc-c++ mingw32-gcc-c++ mingw64-winpthreads-static mingw32-winpthreads-static vulkan-headers spirv-headers-devel spirv-tools git wine-devel.* g++

It could be some packages is not needed (or could possibly be hand-picked removed.. but cba to figure that out).. or that it is some sort of "multilib group package" for fedora, but atleast i was able to compile with the above packages.

Here is my Dockerfile in case you want to create a image for compiling:

# syntax=docker/dockerfile:1
FROM fedora:latest
RUN dnf -y groupinstall "C Development Tools and Libraries"
RUN dnf install -y meson ninja-build glslang mingw-w64-tools glibc-devel.* mingw64-gcc-c++ mingw32-gcc-c++ mingw64-winpthreads-static mingw32-winpthreads-static vulkan-headers spirv-headers-devel spirv-tools git passwd wine-devel.* g++
RUN adduser -G wheel favoriteusername
RUN echo "password" | passwd favoriteusername --stdin

(Replace favoriteusername and password ofc)

Good luck :smile:

EDIT: "nano" is ofc not required.. deleted from the "needed packages"... Same with "passwd".. i only used that for Docker.

[SveSop]

Since i got it working with Docker, and no other feedback is provided - closing issue

[sl1pkn07]

i have the same issue in archlinux

what feedback you need?

greetings

EDIT:

Running test binary command:  /tmp/makepkg/wine-nvlibs-git/src/build_nvlibs/x64/meson-private/sanitycheckc.exe
C compiler for the build machine: cc (gcc 12.2.0 "cc (GCC) 12.2.0")
C linker for the build machine: cc ld.bfd 2.39.0
Build machine cpu family: x86_64
Build machine cpu: x86_64
Host machine cpu family: x86_64
Host machine cpu: x86_64
Target machine cpu family: x86_64
Target machine cpu: x86_64
Running compile:
Working directory:  /tmp/makepkg/wine-nvlibs-git/src/build_nvlibs/x64/meson-private/tmpj8i_wugx
Command line:  winegcc /tmp/makepkg/wine-nvlibs-git/src/build_nvlibs/x64/meson-private/tmpj8i_wugx/testfile.c -o /tmp/makepkg/wine-nvlibs-git/src/build_nvlibs/x64/meson-private/tmpj8i_wugx/output.exe -O3 -march=native -pipe -Wl,--start-group -ldl -Wl,--end-group -mno-avx -mno-avx2 -mfpmath=sse -fwrapv -fno-strict-aliasing -gdwarf-2 -gstrict-dwarf -m64 --no-gnu-unique -D__WINESRC__ -Wno-attributes -Wno-implicit-function-declaration -D_FILE_OFFSET_BITS=64 -O0 -Wl,--allow-shlib-undefined -Wl,-O1,--sort-common,--as-needed -Wl,--file-alignment,4096 -mwindows 

Code:
 int main(void) { return 0; }

Compiler stdout:

Compiler stderr:
 /usr/bin/ld: /usr/bin/../lib/wine/x86_64-unix/libwinecrt0.a(exe_entry.o): in function `__wine_spec_exe_entry':
(.text+0x92): undefined reference to `NtCurrentTeb'
collect2: error: ld returned 1 exit status
winegcc: /usr/bin/gcc failed

nvidia-libs/meson.build:5:0: ERROR: C shared or static library 'dl' not found

seems wine not provide ldl anymore?

[SveSop]

I have no clue. Compiles fine for me on Ubuntu and i cant really be bothered to figure out other distro's libraries and stuff.. libwinecrt0.a might be different for archlinux than Ubuntu... dunno?

[sl1pkn07]

i have use my own build. so i think no

maybe is a LTO foo related https://bugs.winehq.org/show_bug.cgi?id=51051. but in my build i have ensure lto is dissabled. but still happen. so i dont know what happen

one question. some wine related projects swich to mingw, but this still use winelib. any future plans for swich also this project?

greetings

[SveSop]

one question. some wine related projects swich to mingw, but this still use winelib. any future plans for swich also this project?

greetings

The issue with mingw vs winelib is that to make wine libs "talk to" native linux libs you can do it with winelib or if using mingw you have to use wineserver and create a whole bunch of stuff i have absolutely no clue on how to do. If you look at all the development that is being put into this on the wine team, it is WAY beyond my skills to do.

The problem with things like nvcuda.dll is that it is somewhat low-level driver stuff that happens, and you cannot just "make up functions" like you can with nvapi.dll, that can get values from Vulkan and other libraries that are already supported by wine. To make nvcuda.dll use libcuda.so there has to be some sort of "translation" (PE vs ELF) and that is sadly beyond me, so for now it will continue as winelib.

[sl1pkn07]

ok. seems problems with wine 7.21. with 7.22 builds ok

sorry the noise :)

greetings