amdvlk: update to 2024.Q1.3.

[SpidFightFR]

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architecture, (x64-GlibC)

[SpidFightFR]

The issue with x64-musl happens after the update, the original version still builds fine.

[Johnnynator]

The errors in the build logs seem to be mainly missuse of NULL and should be patched to be OL.

Most of the warnings can probably be ignored.

[SpidFightFR]

The errors in the build logs seem to be mainly missuse of NULL and should be patched to be OL.

Most of the warnings can probably be ignored.

Copy that. I'll see what i can do.

It's because of a misuse from Upstream and not a difference between glibc and musl?

[Johnnynator]

Musl and Glibc differ at how they define NULL. (std::nullptr vs (void*)0).
Both of these choices are valid, but std::nullptr can't be implicitely used as a number.

Upstream amdvlk uses NULL as an integer and not a Pointer in a few places

[SpidFightFR]

Musl and Glibc differ at how they define NULL. (std::nullptr vs (void*)0). Both of these choices are valid, but std::nullptr can't be implicitely used as a number.

Upstream amdvlk uses NULL as an integer and not a Pointer in a few places

I see... Thanks for the explanation! If i got some time in the future i'll try to learn more about musl and glibc.

[SpidFightFR]

I made a little test on the rush, replacing NULL, by OL returns undefined and 0L (apparently it's a zero, long number type) returns another error.

I might have made a few mistakes here and there tho. I tried to changed the NULL, that was reported in the error to not create any new error.

But which ones should i change in particular?

[SpidFightFR]

[Nevermind, talked about it on the IRC: TL;DR available here.]