Reported version of slangc inconsistent between target platforms

[tim-rex]

I've noticed that the version reported by slangc -v is not consistent between target platforms of the same release tag

Eg: macos-aarch64

$ ./bin/slangc -v
2025.10.3

windows-aarch64

> slangc.exe -v
2025.10.3

linux-aarch64

$ ./bin/slangc -v
1749352578

It would appear that linux based builds are using an epoch timestamp generated at build time, rather than any form of build tag. I notice similar behaviour from the build provided by the Vulkan SDK distributable, which for the 1.4.313.1 release shows:

$ ./bin/slangc -v
1749040352

That's quite misleading, as I believe the actual distributed version with the Vulkan SDK is v2025.2, while the timestamp above would suggest June 4 2025

[gtong-nv]

Hi @tim-rex , thanks for reporting this.

const char* getBuildTagString()
{
    if (UnownedStringSlice(SLANG_TAG_VERSION) == "0.0.0-unknown")
    {
        // If the tag is unknown, then we will try to get the timestamp of the shared library
        // and use that as the version string, so that we can at least return something
        // that uniquely identifies the build.
        static String timeStampString =
            String(SharedLibraryUtils::getSharedLibraryTimestamp((void*)spCreateSession));
        return timeStampString.getBuffer();
    }
    return SLANG_TAG_VERSION;
}

Looks like for some reason the linux build is not able to get the git tag version so it uses the timestamp. We will look into this

[gtong-nv]

Looks like in the linux build, get_git_version failed

-- Found Git: /usr/bin/git (found version "2.49.0")
fatal: No names found, cannot describe anything.
CMake Warning at cmake/GitVersion.cmake:25 (message):
  Getting SLANG_VERSION_FULL failed:
  /usr/bin/git;-C;/home/runner/work/slang/slang;describe;--tags;--match;v*
  returned 128

  Is this a Git repo with tags?

  Consider settings -DSLANG_VERSION_FULL to specify a version manually
Call Stack (most recent call first):
  CMakeLists.txt:7 (get_git_version)

[tim-rex]

So.. it gets a little wierder for linux-x86_64

$ ./bin/slangc -v
2025.7.1-1-gd84aeeffd

That's not even close to correct, unless the release itself is wrong.. (see link above, taken from the current github releases page) The below looks promising, but I couldn't say how it got the above version tag

$ cat include/slang-tag-version.h 
#define SLANG_TAG_VERSION "2025.10.3"

Edit: I've just now seen the PR.. hopefully that satisfies this example also

[gtong-nv]

Hi @tim-rex, I just checked both Linux and Mac, and all the output from https://github.com/shader-slang/slang/releases should produce valid version info. But the build from the CI might be missing the tag because the CI runner does a shallow fetch for faster turn around. May I ask where did you download the build? Can you try again with the official release builds? Thanks!

[tim-rex]

Hi @gtong-nv

I'm quite sure I was using the official release builds.

In particular, my most recent comment regarding Linux x86_64 was sourced from the below:

https://github.com/shader-slang/slang/releases/download/v2025.10.3/slang-2025.10.3-linux-x86_64.tar.gz

I will have another look and reconfirm this evening for the avoidance of doubt

[tim-rex]

@gtong-nv confirming as before (see below) I note that your PR has not yet been merged (in case you're expecting that to have resolved anything)

Latest 2025.10.4 release sourced from the releases page (per original report) results as follows:

Linux aarch64 (incorrect - note this is the same as reported on the previous release 2025.10.3)

$ wget https://github.com/shader-slang/slang/releases/download/v2025.10.4/slang-2025.10.4-linux-aarch64.tar.gz

$ tar xvfz slang-2025.10.4-linux-aarch64.tar.gz

$ ./bin/slangc -v
1749352578

Linux x86_64 (incorrect - note this is the same as reported on the previous release 2025.10.3)

$ wget https://github.com/shader-slang/slang/releases/download/v2025.10.4/slang-2025.10.4-linux-x86_64.tar.gz

$ tar xvfz slang-2025.10.4-linux-x86_64.tar.gz

$ ./bin/slangc -v
2025.7.1-1-gd84aeeffd

Other platforms that I have access to seem good, as below:

Mac aarch64 (correct)

% curl -L https://github.com/shader-slang/slang/releases/download/v2025.10.4/slang-2025.10.4-macos-aarch64.tar.gz -o slang-2025.10.4-macos-aarch64.tar.gz

% tar xvfz tar xvfz slang-2025.10.4-macos-aarch64.tar.gz

% ./bin/slangc -v
2025.10.4%

Windows aarch64 (correct) Sourced from: https://github.com/shader-slang/slang/releases/download/v2025.10.4/slang-2025.10.4-windows-aarch64.tar.gz

shaderslang>bin\slangc.exe -v
2025.10.4

Windows x86_64 also looks good, emitting 2025.10.4

[gtong-nv]

@tim-rex , Thanks for the detailed repro! I would have to find a Linux aarch64 machine to test and will report back, but for Linux x86_64, here is what I got from the exact same build link

$ wget https://github.com/shader-slang/slang/releases/download/v2025.10.4/slang-2025.10.4-linux-x86_64.tar.gz

$ tar xvfz slang-2025.10.4-linux-x86_64.tar.gz

$ ./bin/slangc -v
2025.10.4

$ md5sum ./bin/slangc
5359677f348e2a32ebb2e2d030644152  ./bin/slangc

$ uname -a
Linux build-gtong-jammy-20250228 5.4.0-204-generic #224-Ubuntu SMP Thu Dec 5 13:38:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

can you check the md5 to see if we are using the same binary ?

[kaizhangNV]

I cannot reproduce the issue on Linux.

[tim-rex]

Well, this is super weird... I found the problem. While my md5sum agrees with yours, I continue to get this strange version..

It gets weirder.. if I run this as root, I get the expected output!

$ bin/slangc -v
2025.7.1-1-gd84aeeffd

$ sudo bin/slangc -v
2025.10.4

Clearly an environment problem.. I've traced this down to the fact that I have the Vulkan SDK installed on the x86_64 machine, and I'm sourcing setup-env.sh from the Vulkan SDK as part of my login shell..

This causes my environment to include the Vulkan SDK in my LD_LIBRARY_PATH

[timk@archon shaderslang]$ echo $LD_LIBRARY_PATH
/home/timk/git/khronos/vulkansdk-linux-x86_64/1.4.313.0/x86_64/lib

[timk@archon shaderslang]$ ./bin/slangc -v
2025.7.1-1-gd84aeeffd

[timk@archon shaderslang]$ unset LD_LIBRARY_PATH
[timk@archon shaderslang]$ ./bin/slangc -v
2025.10.4

strace and ldd both confirm, LD_LIBRARY_PATH is causing slangc to load the Vulkan provided libslang.so This appears to be the same root cause on Linux aarch64

Curiously, this does not occur on MacOS.. (setup-env.sh sets DYLD_LIBRARY_PATH but it is not exported due to SIP)

In any case, ultimately I'd guess this is in-part a symptom of slangc being built with dynamic linking This did get me curious as to how slangc resolves libslangc.so otherwise..

It seems this could perhaps be avoided by using RPATH rather than RUNPATH (or indeed by statically linking the target executable)

$ readelf -a bin/slangc | grep -i RUNPATH
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:$ORIGIN]

The version tag is otherwise correct.

[gtong-nv]

Hi @tim-rex , glad you figured it out! Yes, RUNPATH is searched after LD_LIBRARY_PATH, and it has pros and cons. We will discuss to see if it's preferred to keep as it is.

[tim-rex]

Thanks for looking into it @gtong-nv

FWIW, the MacOS binary appears to use RPATH rather than RUNPATH.

SIP preventing the export of DYLD_LOAD_LIBRARY may not have been a factor on this platform

I am a little surprised this dynamic loader issue hasn't bitten other folks before, tbh.. I'd expect running shader-slang in the context of a Vulkan developer environment to be a relatively common use case

[gtong-nv]

Since RUNPATH is the modern and recommended practice, we'll continue using it as our standard approach. To prevent similar issues in the future, we will document the slang dynamic library loading strategy.

[tim-rex]

Thanks @gtong-nv

Perhaps it would be sensible to have the slangc executable verify the version of the dynamically loaded library, and bail out (or at least warn) if not the expected version?

Even with documentation, I would consider this to be unexpected and undesirable behaviour

Out of curiosity, is there a reason not to provide a statically linked executable?

[gtong-nv]

Out of curiosity, is there a reason not to provide a statically linked executable? @tim-rex thanks for asking!

There are several reasons. Having slangc dynamically linked to the DLL reduces the total size of our binary releases. The dynamic libraries can also be shared between API users and CLI users. It keeps our debugging and support matrix simpler since we don't have to worry about discrepancies between dynamically-linked and statically-linked compiler code or test both versions separately.

Perhaps it would be sensible to have the slangc executable verify the version of the dynamically loaded library, and bail out (or at least warn) if not the expected version?

We discussed internally and agreed that the 99% case for command-line compiles should be with a matching DLL and executable, although a lot of devs drop and replace DLLs to test some quick changes. A warning like "WARNING: Slang version mismatch detected - slangc version is xxx, but loaded slang.dll version is yyy" wound't hurt in this case. I created an issue https://github.com/shader-slang/slang/issues/8234 to track the implementation.