Build warning

[SveSop]

I don't really have it in me to figure out how exactly that make_nvml script generates nvml.c file, so i just attach a log with some compile warnings i got today (using wine-staging-7.16)

I guess it might be some wine update causing this, cos the last time i compiled wine-nvml i dont remember getting this.

compile.zip

[Saancreed]

I think it's some bug coming from old version of mingw? I had the same when I tried to build with Debian in my GitHub Actions workflow here but later I switched CI to Arch and all the warnings were gone.

My script generates %llu format for arguments of type unsigned long long, which as far as I know is C99-compliant way of printing such numbers but apparently mingw (or GCC 10, not sure which one is at fault here) seems to not recognize it.

While searching for possible solutions, I've found https://stackoverflow.com/questions/13590735/printf-long-long-int-in-c-with-gcc which suggests that mingw can be just unaware of C runtime actually having support for %llu and generates warnings about using it because historically Windows's runtime used to not have this. But I think we can just safely ignore it because compiled nvml.dll is going to call into Wine's CRT which shouldn't have any problem here.

Have you tried compiling with newer mingw?

[SveSop]

I can try compiling with arch in my Docker image just to see. Ubuntu is still stuck on mingw 10.3 unfortunately, so i will not venture into creating a custom 11.x version of that since it is a bit more involved.

The error did not really make much sense to me tho, as %llu is normally working just fine for unsigned long long, but i know i sometimes have issues needing to use %PRIu64 or somecrap, especially when doing 32/64 bit compiles with winegcc.
Maybe ill try experiment with -std=c99 flag for my ancient mingw version? 😄 Ill let you know.

PS. I am fairly certain i did NOT have this warning the last time i did a compile, and afaik the only thing changed on my system since then is my system installed wine version, but my memory may deceive me as it often does 😉

[SveSop]

No dice fiddling with Ubuntu mingw-w64 flags... Compiles fine with arch in a docker image.

Seemingly does not make a difference for the binary as it works just fine, but i don't like warnings 😀

Recommended for build: mingw-w64 >= (GCC 12)

Closing issue due to "Ubuntu too old build system"

[SveSop]

Hmm.. The nvml binaries i compiled with my Arch docker image actually did not work for me.. for some strange reason.

I recompiled (with the warnings) with my regular ubuntu setup, and copied the binaries++ into my wine binary folder and did a wineboot, and wham - working again.

Weird. Ill see if i can do some testing with your CI binaries if i can hack together a small nvml test proggy on a fresh prefix before laying this to rest.

[Saancreed]

Hmm.. The nvml binaries i compiled with my Arch docker image actually did not work for me.. for some strange reason.

That's actually kind of expected: ELF side of each module is compiled with host-native gcc and linked to whatever version of glibc was available at build time. So, ELF binaries compiled on Arch Linux will later require at least that version of glibc or newer, which Ubuntu probably doesn't provide yet.

But if the binaries built with Ubuntu toolchain work for you despite the warnings, I guess the way to go is just use them and ignore the warnings (which, as I mentioned earlier, are most likely false positives anyway).

[SveSop]

Yeah, that sounds reasonable. This is due to the ELF part of the lib then right? Like dxvk-nvapi or dxvk/vkd3d-proton does not have this problem as it is a "pure" windows binary in that sense?

[SveSop]

I did not find any simple examples of nvml usage that dynamically loads nvml.dll, so i hacked together a little snippit if you want to use for local testing?

#include <windows.h>
#include <stdio.h>
#include "nvml.h"

typedef nvmlReturn_t result;

typedef result(WINAPI *INITPROC)(void);
typedef result(WINAPI *VERPROC)(char*, unsigned int);
typedef result(WINAPI *SHUTPROC)(void);

int main(void)
{
    HMODULE hModule = LoadLibrary("nvml.dll");
    nvmlReturn_t ret;
    char version[16];
    unsigned int length = 16;

    if (hModule != NULL)
    {
        INITPROC Init = (INITPROC)GetProcAddress(hModule, "nvmlInit_v2");
        VERPROC Version = (VERPROC)GetProcAddress(hModule, "nvmlSystemGetDriverVersion");
        SHUTPROC Shutdown = (SHUTPROC)GetProcAddress(hModule, "nvmlShutdown");

        if (!Init || !Shutdown || !Version)
        {
            FreeLibrary(hModule);
            printf("Failed to load all functions!\n");
            return 0;
        }
        else
        ret = Init();
        if(!ret) printf("Init success!\n");

        ret = Version(version, length);
        if(!ret) printf("NVML Version: %s\n", version);

        ret = Shutdown();
        if(!ret) printf("Shutdown success!\n");

        FreeLibrary(hModule);
    }
}

Init the lib, print the nvml version and shutdown and exit. Does not work with arch compiled binaries on my Ubuntu box as you point out above. I assume older glibc compiled binaries work with arch?
(Horrible code im sure, but well... live and learn i guess)

Attaching binary .exe.
nvml_test.zip

[Saancreed]

This is due to the ELF part of the lib then right? Like dxvk-nvapi or dxvk/vkd3d-proton does not have this problem as it is a "pure" windows binary in that sense?

Yup. While on the other hand wine-nvoptix would have a similar issue (except that one is compiled as a single ELF binary that only pretends to be PE) because it also links to system glibc.

I did not find any simple examples of nvml usage that dynamically loads nvml.dll, so i hacked together a little snippit if you want to use for local testing?

I have my own one that I use to compare NVML to NVAPI, here, plus a bunch of quickly written and later discarded programs which are not really worth mentioning. But for some real action you could extract nvidia-smi.exe from NVIDIA's Windows driver package and try to run that, assuming that you don't mind having no access to the source code.

I assume older glibc compiled binaries work with arch?

They should, at least I remember not having to rebuild mine when Arch upgraded from 2.35 to 2.36. But I've never tried building on Ubuntu and then using binaries produced this way on Arch. And I'm not exactly tempted to try it anytime soon, because last time I tried to build anything on Ubuntu it felt like walking a minefield, especially in the Ubuntu environment provided by GitHub Actions runners.

(Horrible code im sure, but well... live and learn i guess)

As if my own test app was any better with its inconsistency in loading function pointers and clear abuse of preprocessor macros 😅

Attaching binary .exe.

Fwiw that binary works fine on my Arch system with wine-nvml also built on Arch (using the PKGBUILD from the repo).

$ WINEDEBUG=-all,+nvml wine nvml_test.exe
fsync: up and running.
012c:trace:nvml:DllMain (00000002FD7C0000, 1, 0000000000000000)
012c:trace:nvml:nvmlInit_v2 ()
Init success!
012c:trace:nvml:nvmlSystemGetDriverVersion (000000000067FD00, 16)
NVML Version: 515.49.06
012c:trace:nvml:nvmlShutdown ()
Shutdown success!
012c:trace:nvml:DllMain (00000002FD7C0000, 0, 0000000000000000)

[SveSop]

The attached nvml_test.exe was built with mingw-w64, so does not care about ELF/glibc stuff anyway. I would assume it would work just the same if built in arch or windows for that matter.

Building wine on ubuntu is a pita, but building "minor libs" usually is not too horrible unless latest of the latest is needed in terms of packages. (I have issues with libFAudio seemingly needing libSDL2 2.24 now which is not available yet).

Still odd that mingw-w64 would complain about this, other than the peculiarity of building using winegcc -b x86_64-w64-mingw32 vs. using x86_64-w64-mingw32-gcc directly. Could winegcc somehow pick up some weird flags or wine changes that might not have made this happen when using older wine version (and thus older winegcc)? Hmm.. ill experiment with this and see if i can point this to some old wine binaries i have.

[Saancreed]

@SveSop dedd119 should be enough to workaround this. Could you please check if binaries from here work for you as intended (especially when calling a function that uses %llu format with WINEDEBUG=+nvml, e.g. nvmlDeviceGetSamples or nvmlDeviceGetProcessUtilization)?

[SveSop]

Don't really know of anything using those calls to test, so i need to make some sort of nvml program to do that i guess.... With my extremely limited skills it will take some time to figure that out 😄

[Saancreed]

No worries, there's no rush 🙂

[SveSop]

Of all the functions using %llu i cannot really figure out how to use it for anything interesting? What values should i be able to obtain from nvmlDeviceGetProcessUtilization? I need to actually run something then, and set up some sort of test from that.. I do not really believe this would be actually useful for much, so i kind of am not willing to fiddle for hours on end trying to set up some weird test-case scenario just to see if %llu borks out...

[Saancreed]

I'm not sure just yet. But I'll try to write a test case myself, soonish.

[Saancreed]

Okay, I think all we need to do is to call any function that has an unsigned long long parameter and we don't need to care what the function does, or whether it even succeeds. So, the following program should be enough, even if the call is expected to return an error anyway:

#include <stddef.h>
#include "nvml.h"

int main(void)
{
    nvmlDeviceRegisterEvents(NULL, ~(unsigned long long)0, NULL);
}

Build with winegcc -b x86_64-w64-mingw32-gcc -lnvml (and pass correct -I to make sure nvml.h can be found) then run with WINEDEBUG=-all,+nvml. All I care about is whether Wine's logs contain a line similar to trace:nvml:nvmlDeviceRegisterEvents (0000000000000000, 18446744073709551615, 0000000000000000). If they do, and 18446744073709551615 is correctly printed there, we can just suppress the warnings because they seem to be just wrong. If we get something else, we would have to handle this in some other way.

[Saancreed]

Hopefully should be resolved after 788a138.