[C++] Linking error in custom Module

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By DNKpp

Hey there,
currently I’m trying to setup a Dev and Debug Client for my online Game. Most of the code is placed in an external lib which will be linked as a custom module in godot. The code compiles fine, but during linkage it fails.
I already tried to setup another simple cmd project to test the lib, and there it works fine.

My guess is, that I compile that lib with different compiler flags. I compiled my lib with /MTd /Z7 and /std:c++17.

I’m working on a Windows 10 Machine with Visual Studio 2019 and enabled c++17

This is the error:

1>------ Build started: Project: godot, Configuration: debug x64 ------
1>Starting SCons
1>**********************************************************************
1>** Visual Studio 2019 Developer Command Prompt v16.2.2
1>** Copyright (c) 2019 Microsoft Corporation
1>**********************************************************************
1>[vcvarsall.bat] Environment initialized for: 'x86_x64'
1>scons: Reading SConscript files ...
1>Configuring for Windows: target=debug, bits=default
1>Found MSVC compiler: x86_amd64
1>Compiled program architecture will be a 64 bit executable (forcing bits=64).
1>YASM is necessary for WebM SIMD optimizations.
1>WebM SIMD optimizations are disabled. Check if your CPU architecture, CPU bits or platform are supported!
1>Checking for C header file mntent.h... (cached) no
1>scons: done reading SConscript files.
1>
1>scons : warning : you do not seem to have the pywin32 extensions installed;
1>  parallel (-j) builds may not work reliably with open Python files.
1>scons: Building targets ...
1>File "C:\Programs\SCons\scons-local-3.1.0\SCons\Script\Main.py", line 609, in _scons_internal_warning
1>Compiling ==> modules\CoregroundsEngine\CoregroundsEngine.cpp
1>CoregroundsEngine.cpp
1>progress_finish(["progress_finish"], [])
1>Linking Static Library ==> modules\modules.windows.tools.64.lib
1>Linking Program        ==> bin\godot.windows.tools.64.exe
1>   Creating library bin\godot.windows.tools.64.lib and object bin\godot.windows.tools.64.exp
1>modules.windows.tools.64.lib(CoregroundsEngine.windows.tools.64.obj) : error LNK2019: unresolved external symbol "public: void __cdecl fw::client::Engine::tick(void)" (?tick@Engine@client@fw@@QEAAXXZ) referenced in function "public: void __cdecl DebugClient_Pimpl::tick(void)" (?tick@DebugClient_Pimpl@@QEAAXXZ)
1>bin\godot.windows.tools.64.exe : fatal error LNK1120: 1 unresolved externals
1>scons: *** [bin\godot.windows.tools.64.exe] Error 1120
1>scons: building terminated because of errors.
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.MakeFile.Targets(44,5): error MSB3073: The command "echo Starting SCons && cmd /V /C set "plat=x64" ^& (if "x64"=="x64" (set "plat=x86_amd64")) ^& set "tools=yes" ^& (if "debug"=="release" (set "tools=no")) ^& call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" !plat! ^& scons --directory="G:\Projects\Coregrounds_Client\godot" platform=windows progress=no target=debug tools=!tools! -j8" exited with code 2.
1>Done building project "godot.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

and this is my SCsub file:

#!/usr/bin/env python

Import('env')
import os

env_CoregroundsEngine = env.Clone()
env_CoregroundsEngine.add_source_files(env.modules_sources, "*.cpp") # Add all cpp files to the build

AddOption('--cg_dir',
		dest='cg_dir',
		type='string',
		nargs=1,
		action='store',
		metavar='DIR',
		help='path to Coregrounds'
)

CG_DIR = GetOption('cg_dir')
if not GetOption('cg_dir'):
	CG_DIR = str(os.environ.get('COREGROUNDS_DIR', ""))

#print(CG_DIR)

if not GetOption('help'):
	env_CoregroundsEngine.Append(CPPPATH=[
		CG_DIR + '/Framework/include',
		CG_DIR + '/Serialize/include',
		CG_DIR + '/Utility',
		CG_DIR + '/Dependencies/georithm',
		CG_DIR + '/Dependencies/SimpleLibV2/src',
		CG_DIR + '/Dependencies',
		CG_DIR + '/Dependencies/protobuf/src'
	])

	env_CoregroundsEngine.Append(LIBPATH=[
		CG_DIR + '/out/build/x64-Debug/Framework'
	])
	env_CoregroundsEngine.Append(LIBS=[
		'Framework'
	])

	env_CoregroundsEngine.Append(CXXFLAGS=['/std:c++17'])

I’m really looking forward for your help :wink:

Is that symbol inside your Framework.lib? If so:
Not sure if it’ll help, but what is your lib files name? Try changing it to Framework.windows.tools.64.lib if you haven’t already. I remember that linking against external libraries requires this naming convention, which is defined somewhere inside the scons files of godot itself.

omggomb | 2019-08-18 07:30

Thanks for your reply. Yes indeed, the symbol is in the Framework lib. The probleme here was, that I appended the lib and libpath to the module env instead of the global godot env. It seems the example in the docu is a little bit wrong about that. And yes, I had to rename my lib to match this specific suffix, but the main issue was, that godot never tried to link against my lib, because the module env never links anything.

DNKpp | 2019-08-18 13:19

Could you please write that also as an answer and mark it as such, because this helps when skimming through these Q&As in a hurry (and desperation :D).

omggomb | 2019-08-18 13:43

:bust_in_silhouette: Reply From: DNKpp

As already mentioned in the comments, I found the solution for that issue.

The probleme here was, that I appended the lib and libpath to the module env instead of the global godot env. It seems the example in the docu is a little bit wrong about that. And yes, I had to rename my lib to match this specific suffix, but the main issue was, that godot never tried to link against my lib, because the module env never links anything.

That means, I had to write the following:

    env.Append(LIBPATH=[
        CG_DIR + '/out/build/x64-Debug/Framework'
    ])
    env.Append(LIBS=[
        'Framework'
    ])

Pay special attention to the env.Append; do NOT use the module env for both!

After that, I still got an error, but this time the Framework.windows.tools.64.lib was not found. The solution for that is easy, just rename your lib like that and it will successfully link.