Trouble linking third party library

[LouChiSoft]

Godot Version

v4.3.beta.custom_build

Question

Hi, I’m trying to link a pre-compiled third party DLL to my C++ module and seem to be having a bit of an issue. My SCsub file currently looks like this:

Import('env')

env_slang = env.Clone()

env_slang.add_source_files(env.modules_sources, "*.cpp")

env_slang.Append(CPPPATH=[env_slang.Dir("external/include")])
env_slang.Append(LIBPATH=[env_slang.Dir("external/lib")])
env_slang.Append(LIBS=["slang"])

But the problem with this is as soon as I use any of the functions from the third party library I get an unresolved external. Which implies it’s not actually linking to the library in the first place.

Other solutions I have tried are:

• changing env_slang to env when appending the library path and the libs list. But that changes the error from unresolved external to missing a file that Godot thinks should have been built.
• Manually linking via command line passed to the CCFLAGS variable, but in all cases that has resulted in the compiler thinking that the third party library is a source file of some kind, not a library.

My module folder curently looks like this:

module_root
│   config.py
│   register_types.cpp
│   register_types.h
│   SCsub
│   slang_compute_shader.cpp
│   slang_compute_shader.h
│   slang_shader_base.cpp
│   slang_shader_base.h
│
└───external
    ├───include
    │   └───slang
    │           slang-com-helper.h
    │           slang-com-ptr.h
    │           slang-gfx.h
    │           slang.h
    │
    └───lib
            slang.dll
            slang.lib

Any help would be appreciated

Post Solution Edit:
Based on the solution linked below my SCsub now looks like this for others to reference:

Import('env')

env_slang = env.Clone()
env_slang.add_source_files(env.modules_sources, "*.cpp")
env_slang.Append(CPPPATH=[env_slang.Dir("external/include")])

env.Append(LIBS=[File("external/lib/slang.lib")])

[pennyloafers]

I’m pretty sure you need to add it to the main environment rather then the component environment.

Binding to external libraries

env.Append(LIBPATH=[env_slang.Dir("external/lib")])
env.Append(LIBS=["slang"])

[LouChiSoft]

So I did try that, doesn’t work either. It complains that the linker can’t find the file slang.windows.editor.double.x86_64.lib. Almost as if it was expecting to have built that file itself instead of just linking to the file I provided.

I even tried renaming my slang.lib and slang.dll files to match the one godot was expecting with no difference in error message.

[pennyloafers]

I wouldn’t rename the extension. and in some sense it shouldn’t matter.

oh did you try Import('env_module')

[LouChiSoft]

oh did you try Import(‘env_module’)

Just tried. Can’t import it, env_module is a non-existent variable apparently.

[pennyloafers]

I helped a guy here once.

Linking error for libgmic

Hello @pennyloafers! Thank you so much for your help, your tipps brought me on the right track! I was able to get it to build with your changes to the SCsub file, unfortunatelly I only got it to work with MinGW yet. Since this would affect other parts of the project I’m not free to just substitute the build toolchain. The library is found, and the link command generated by scons seems fine, but the linking aborts with the following error: modules\gmic\lib\libgomp-1.dll : fatal error LNK1107:…

I’m not sure what your issue is. could you provide the raw error?

[LouChiSoft]

Figured it out, the reason that env_module was undefined is because it was env_modules. Spotted that in the other post. But I didn’t need that if I changed env.Append(LIBS=["slang"]) to env.Append(LIBS=[File("external/lib/slang.lib")]).

Or at least it builds, need to actually test it runs with the DLL alongside it. I will run it and get back to you

[LouChiSoft]

Tested it, it runs. Resources and Nodes show up as expected and if I remove the DLL from alongside the engine it fails to launch. All signs indicate it’s working now.

Really not sure why I have to specify the file being linked to such specificity, but working is better than not working. So I am not gonna complain too much

Cheers for the assist.

[pennyloafers]

I do agree that the solution I found in the other post doesn’t seem completely correct. There were some odd things from the Godot’s build system that seemed a little weird like it wanted to look for libraries in platforms, instead of modules.

maybe the official example is incorrect, or outdated.

[LouChiSoft]

I had considered opening an issue on the GitHub. But I don’t know nearly enough about Godot’s build system to conclusively say it’s a bug and needs fixing.