Error lnk2001 unresolved external symbol purecall

description	title	ms.date	f1_keywords	helpviewer_keywords	ms.assetid
Learn more about: Linker Tools Error LNK2001	Linker Tools Error LNK2001	10/22/2021	LNK2001	LNK2001	dc1cf267-c984-486c-abd2-fd07c799f7ef

unresolved external symbol «symbol«

The compiled code makes a reference or call to symbol. The symbol isn’t defined in any libraries or object files searched by the linker.

This error message is followed by fatal error LNK1120. To fix error LNK1120, first fix all LNK2001 and LNK2019 errors.

There are many ways to get LNK2001 errors. All of them involve a reference to a function or variable that the linker can’t resolve, or find a definition for. The compiler can identify when your code doesn’t declare a symbol, but not when it doesn’t define one. That’s because the definition may be in a different source file or library. If your code refers to a symbol, but it’s never defined, the linker generates an error.

What is an unresolved external symbol?

A symbol is the internal name for a function or global variable. It’s the form of the name used or defined in a compiled object file or library. A global variable is defined in the object file where storage is allocated for it. A function is defined in the object file where the compiled code for the function body is placed. An external symbol is one referenced in one object file, but defined in a different library or object file. An exported symbol is one that’s made publicly available by the object file or library that defines it.

To create an application or DLL, every symbol used must have a definition. The linker must resolve, or find the matching definition for, every external symbol referenced by each object file. The linker generates an error when it can’t resolve an external symbol. It means the linker couldn’t find a matching exported symbol definition in any of the linked files.

Compilation and link issues

This error can occur:

• When the project is missing a reference to a library (.LIB) or object (.OBJ) file. To fix this issue, add a reference to the required library or object file to your project. For more information, see lib Files as linker input.

• When the project has a reference to a library (.LIB) or object (.OBJ) file that in turn requires symbols from another library. It may happen even if you don’t call functions that cause the dependency. To fix this issue, add a reference to the other library to your project. For more information, see Understanding the classical model for linking: Taking symbols along for the ride.

• If you use the /NODEFAULTLIB or /Zl options. When you specify these options, libraries that contain required code aren’t linked into the project unless you’ve explicitly included them. To fix this issue, explicitly include all the libraries you use on the link command line. If you see many missing CRT or Standard Library function names when you use these options, explicitly include the CRT and Standard Library DLLs or library files in the link.

• If you compile using the /clr option. There may be a missing reference to .cctor. For more information on how to fix this issue, see Initialization of mixed assemblies.

• If you link to the release mode libraries when building a debug version of an application. Similarly, if you use options /MTd or /MDd or define _DEBUG and then link to the release libraries, you should expect many potential unresolved externals, among other problems. Linking a release mode build with the debug libraries also causes similar problems. To fix this issue, make sure you use the debug libraries in your debug builds, and retail libraries in your retail builds.

• If your code refers to a symbol from one library version, but you link a different version of the library. Generally, you can’t mix object files or libraries that are built for different versions of the compiler. The libraries that ship in one version may contain symbols that can’t be found in the libraries included with other versions. To fix this issue, build all the object files and libraries with the same version of the compiler before linking them together. For more information, see C++ binary compatibility between Visual Studio versions.

• If library paths are out of date. The Tools > Options > Projects > VC++ Directories dialog, under the Library files selection, allows you to change the library search order. The Linker folder in the project’s Property Pages dialog box may also contain paths that could be out of date.

• When a new Windows SDK is installed (perhaps to a different location). The library search order must be updated to point to the new location. Normally, you should put the path to new SDK include and lib directories in front of the default Visual C++ location. Also, a project containing embedded paths may still point to old paths that are valid, but out of date. Update the paths for new functionality added by the new version that’s installed to a different location.

• If you build at the command line, and have created your own environment variables. Verify that the paths to tools, libraries, and header files go to a consistent version. For more information, see Use the MSVC toolset from the command line.

Coding issues

This error can be caused by:

• Mismatched case in your source code or module-definition (.def) file. For example, if you name a variable var1 in one C++ source file and try to access it as VAR1 in another, this error is generated. To fix this issue, use consistently spelled and cased names.

• A project that uses function inlining. It can occur when you define the functions as inline in a source file, rather than in a header file. Inlined functions can’t be seen outside the source file that defines them. To fix this issue, define the inlined functions in the headers where they’re declared.

• Calling a C function from a C++ program without using an extern "C" declaration for the C function. The compiler uses different internal symbol naming conventions for C and C++ code. The internal symbol name is what the linker looks for when resolving symbols. To fix this issue, use an extern "C" wrapper around all declarations of C functions used in your C++ code, which causes the compiler to use the C internal naming convention for those symbols. Compiler options /Tp and /Tc cause the compiler to compile files as C++ or C, respectively, no matter what the filename extension is. These options can cause internal function names different from what you expect.

• An attempt to reference functions or data that don’t have external linkage. In C++, inline functions and const data have internal linkage unless explicitly specified as extern. To fix this issue, use explicit extern declarations on symbols referred to outside the defining source file.

• A missing function body or variable definition. This error is common when you declare, but don’t define, variables, functions, or classes in your code. The compiler only needs a function prototype or extern variable declaration to generate an object file without error, but the linker can’t resolve a call to the function or a reference to the variable because there’s no function code or variable space reserved. To fix this issue, make sure to define every referenced function and variable in a source file or library you link.

• A function call that uses return and parameter types or calling conventions that don’t match the ones in the function definition. In C++ object files, Name decoration encodes the calling convention, class or namespace scope, and return and parameter types of a function. The encoded string becomes part of the final decorated function name. This name is used by the linker to resolve, or match, calls to the function from other object files. To fix this issue, make sure the function declaration, definition, and calls all use the same scopes, types, and calling conventions.

• C++ code you call, when you include a function prototype in a class definition, but don’t include the implementation of the function. To fix this issue, be sure to provide a definition for all class members you call.

• An attempt to call a pure virtual function from an abstract base class. A pure virtual function has no base class implementation. To fix this issue, make sure all called virtual functions are implemented.

• Trying to use a variable declared within a function (a local variable) outside the scope of that function. To fix this issue, remove the reference to the variable that isn’t in scope, or move the variable to a higher scope.

• When you build a Release version of an ATL project, producing a message that CRT startup code is required. To fix this issue, do one of the following,

  • Remove _ATL_MIN_CRT from the list of preprocessor defines to allow CRT startup code to be included. For more information, see General property page (Project).

  • If possible, remove calls to CRT functions that require CRT startup code. Instead, use their Win32 equivalents. For example, use lstrcmp instead of strcmp. Known functions that require CRT startup code are some of the string and floating point functions.

Consistency issues

There’s currently no standard for C++ name decoration between compiler vendors, or even between different versions of the same compiler. Object files compiled with different compilers may not use the same naming scheme. Linking them can cause error LNK2001.

Mixing inline and non-inline compile options on different modules can cause LNK2001. If a C++ library is created with function inlining turned on (/Ob1 or /Ob2) but the corresponding header file describing the functions has inlining turned off (no inline keyword), this error occurs. To fix this issue, define the functions inline in the header file you include in other source files.

If you use the #pragma inline_depth compiler directive, make sure you’ve set a value of 2 or greater, and make sure you also use the /Ob1 or /Ob2 compiler option.

This error can occur if you omit the LINK option /NOENTRY when you create a resource-only DLL. To fix this issue, add the /NOENTRY option to the link command.

This error can occur if you use incorrect /SUBSYSTEM or /ENTRY settings in your project. For example, if you write a console application and specify /SUBSYSTEM:WINDOWS, an unresolved external error is generated for WinMain. To fix this issue, make sure you match the options to the project type. For more information on these options and entry points, see the /SUBSYSTEM and /ENTRY linker options.

Exported .def file symbol issues

This error occurs when an export listed in a .def file isn’t found. It could be because the export doesn’t exist, is spelled incorrectly, or uses C++ decorated names. A .def file doesn’t take decorated names. To fix this issue, remove unneeded exports, and use extern "C" declarations for exported symbols.

Use the decorated name to find the error

The C++ compiler and linker use Name Decoration, also known as name-mangling. Name decoration encodes extra information about the type of a variable in its symbol name. The symbol name for a function encodes its return type, parameter types, scope, and calling convention. This decorated name is the symbol name the linker searches for to resolve external symbols.

A link error can result if the declaration of a function or variable doesn’t exactly match the definition of the function or variable. That’s because any difference becomes part of the symbol name to match. The error can happen even if the same header file is used in both the calling code and the defining code. One way it may occur is if you compile the source files by using different compiler flags. For example, if your code is compiled to use the __vectorcall calling convention, but you link to a library that expects clients to call it using the default __cdecl or __fastcall calling convention. In this case, the symbols don’t match because the calling conventions are different.

To help you find the cause, the error message shows you two versions of the name. It displays both the «friendly name,» the name used in source code, and the decorated name (in parentheses). You don’t need to know how to interpret the decorated name. You can still search for and compare it with other decorated names. Command-line tools can help to find and compare the expected symbol name and the actual symbol name:

• The /EXPORTS and /SYMBOLS options of the DUMPBIN command-line tool are useful here. They can help you discover which symbols are defined in your .dll and object or library files. You can use the symbols list to verify that the exported decorated names match the decorated names the linker searches for.

• In some cases, the linker can only report the decorated name for a symbol. You can use the UNDNAME command-line tool to get the undecorated form of a decorated name.

Additional resources

For more information, see the Stack Overflow question «What is an undefined reference/unresolved external symbol error and how do I fix it?».

Hi Guys

I am a newbie to FreeCAD community and trying to compile FreeCAD. Once successfuly produced Visual Studio 2015 Solution I get the following output during compilation and can’t identify the reason. Please, provide some suggestions.

Rafal

1>—— Rebuild All started: Project: ZERO_CHECK, Configuration: Debug x64 ——
1> Checking Build System
1> CMake does not need to re-run because D:/FreeCAD/Build/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Build/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/3rdParty/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/3rdParty/salomesmesh/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Base/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Main/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Points/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Points/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Complete/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Complete/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Test/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Image/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Image/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Mesh/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Mesh/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Part/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Part/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Material/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/PartDesign/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/PartDesign/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Raytracing/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Raytracing/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Drawing/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Drawing/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Sketcher/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Sketcher/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Robot/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Robot/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/ReverseEngineering/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/ReverseEngineering/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/MeshPart/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/MeshPart/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Draft/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Start/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Start/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Idf/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Import/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Import/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Inspection/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Inspection/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Arch/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Assembly/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Assembly/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Fem/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Fem/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Sandbox/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Sandbox/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Ship/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/OpenSCAD/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Plot/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Spreadsheet/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Spreadsheet/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Path/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Mod/Path/App/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/src/Doc/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/data/CMakeFiles/generate.stamp is up-to-date.
1> CMake does not need to re-run because D:/FreeCAD/Build/data/examples/CMakeFiles/generate.stamp is up-to-date.
2>—— Rebuild All started: Project: SMDS, Configuration: Debug x64 ——
2> Building Custom Rule D:/FreeCAD/freecad-master/src/3rdParty/salomesmesh/CMakeLists.txt
2> CMake does not need to re-run because D:FreeCADBuildsrc3rdPartysalomesmeshCMakeFilesgenerate.stamp is up-to-date.
2> SMDS_EdgePosition.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_FaceOfEdges.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_FaceOfNodes.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_FacePosition.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_IteratorOfElements.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_MemoryLimit.cpp
2> SMDS_Mesh.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_MeshEdge.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_MeshElement.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_MeshElementIDFactory.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_MeshFace.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_MeshGroup.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_MeshIDFactory.cpp
2> SMDS_MeshNode.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_MeshObject.cpp
2> SMDS_MeshVolume.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_PolygonalFaceOfNodes.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_PolyhedralVolumeOfNodes.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_Position.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_QuadraticEdge.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> Generating Code…
2> Compiling…
2> SMDS_QuadraticFaceOfNodes.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_QuadraticVolumeOfNodes.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_SpacePosition.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_VertexPosition.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_VolumeOfFaces.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_VolumeOfNodes.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> SMDS_VolumeTool.cpp
2> Unknown compiler version — please run the configure tests and report the results
2> Generating Code…
2> Creating library D:/FreeCAD/Build/lib/Debug/SMDS_d.lib and object D:/FreeCAD/Build/lib/Debug/SMDS_d.exp
2>SMDS_VertexPosition.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_VolumeOfFaces.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_VolumeOfNodes.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_VolumeTool.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_QuadraticEdge.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_QuadraticFaceOfNodes.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_QuadraticVolumeOfNodes.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_SpacePosition.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_MeshVolume.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_PolygonalFaceOfNodes.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_PolyhedralVolumeOfNodes.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_Position.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_MeshElementIDFactory.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_MeshFace.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_MeshGroup.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_MeshNode.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_IteratorOfElements.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_Mesh.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_MeshEdge.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_MeshElement.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_EdgePosition.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_FaceOfEdges.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_FaceOfNodes.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_FacePosition.obj : error LNK2001: unresolved external symbol _purecall
2>SMDS_VolumeOfFaces.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_VolumeOfNodes.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_VolumeTool.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_QuadraticEdge.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_QuadraticFaceOfNodes.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_QuadraticVolumeOfNodes.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_VertexPosition.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_MeshNode.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_MeshVolume.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_PolygonalFaceOfNodes.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_PolyhedralVolumeOfNodes.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_MeshElementIDFactory.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_MeshFace.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_MeshGroup.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_MeshIDFactory.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_IteratorOfElements.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_Mesh.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_MeshEdge.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_MeshElement.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_EdgePosition.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_FaceOfEdges.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_FaceOfNodes.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_FacePosition.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter
2>SMDS_VolumeTool.obj : error LNK2001: unresolved external symbol memcpy
2>SMDS_MeshGroup.obj : error LNK2001: unresolved external symbol memcpy
2>SMDS_PolyhedralVolumeOfNodes.obj : error LNK2001: unresolved external symbol memcpy
2>SMDS_VertexPosition.obj : error LNK2001: unresolved external symbol memcpy
2>SMDS_VolumeOfNodes.obj : error LNK2001: unresolved external symbol memcpy
2>SMDS_EdgePosition.obj : error LNK2001: unresolved external symbol memcpy
2>SMDS_FacePosition.obj : error LNK2001: unresolved external symbol memcpy
2>SMDS_Mesh.obj : error LNK2001: unresolved external symbol memcpy
2>SMDS_MeshElement.obj : error LNK2001: unresolved external symbol memcpy
2>SMDS_VolumeTool.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_QuadraticFaceOfNodes.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_QuadraticVolumeOfNodes.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_VertexPosition.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_VolumeOfNodes.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_MeshElement.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_MeshGroup.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_PolygonalFaceOfNodes.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_PolyhedralVolumeOfNodes.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_EdgePosition.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_FaceOfNodes.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_FacePosition.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_Mesh.obj : error LNK2001: unresolved external symbol __imp_memmove
2>SMDS_VolumeOfNodes.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_VolumeTool.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_QuadraticFaceOfNodes.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_QuadraticVolumeOfNodes.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_VertexPosition.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_VolumeOfFaces.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_MeshNode.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_PolygonalFaceOfNodes.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_PolyhedralVolumeOfNodes.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_QuadraticEdge.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_Mesh.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_MeshEdge.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_MeshElement.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_MeshGroup.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_EdgePosition.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_FaceOfEdges.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_FaceOfNodes.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_FacePosition.obj : error LNK2001: unresolved external symbol strlen
2>SMDS_VolumeOfFaces.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_VolumeOfNodes.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_VolumeTool.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_QuadraticEdge.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_QuadraticFaceOfNodes.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_QuadraticVolumeOfNodes.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_VertexPosition.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_MeshNode.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_MeshVolume.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_PolygonalFaceOfNodes.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_PolyhedralVolumeOfNodes.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_MeshElementIDFactory.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_MeshFace.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_MeshGroup.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_MeshIDFactory.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_IteratorOfElements.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_Mesh.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_MeshEdge.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_MeshElement.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_EdgePosition.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_FaceOfEdges.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_FaceOfNodes.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>SMDS_FacePosition.obj : error LNK2001: unresolved external symbol __imp__CrtDbgReportW
2>MSVCRTD.lib(throw_bad_alloc.obj) : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_VertexPosition.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_VolumeOfFaces.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_VolumeOfNodes.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_VolumeTool.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_QuadraticEdge.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_QuadraticFaceOfNodes.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_QuadraticVolumeOfNodes.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_SpacePosition.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_MeshNode.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_MeshVolume.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_PolygonalFaceOfNodes.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_PolyhedralVolumeOfNodes.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_MeshElementIDFactory.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_MeshFace.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_MeshGroup.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_MeshIDFactory.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_IteratorOfElements.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_Mesh.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_MeshEdge.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_MeshElement.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_EdgePosition.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_FaceOfEdges.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_FaceOfNodes.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_FacePosition.obj : error LNK2001: unresolved external symbol _CxxThrowException
2>SMDS_VolumeOfNodes.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_VolumeTool.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>MSVCRTD.lib(gshandlereh.obj) : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_QuadraticVolumeOfNodes.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_SpacePosition.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_VertexPosition.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_VolumeOfFaces.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_PolyhedralVolumeOfNodes.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_Position.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_QuadraticEdge.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_QuadraticFaceOfNodes.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_MeshNode.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_MeshObject.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_MeshVolume.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_PolygonalFaceOfNodes.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_MeshElementIDFactory.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_MeshFace.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_MeshGroup.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_MeshIDFactory.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_IteratorOfElements.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_Mesh.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_MeshEdge.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_MeshElement.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_EdgePosition.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_FaceOfEdges.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_FaceOfNodes.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_FacePosition.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
2>SMDS_QuadraticFaceOfNodes.obj : error LNK2001: unresolved external symbol __imp__wassert
2>SMDS_VolumeTool.obj : error LNK2001: unresolved external symbol __imp__wassert
2>SMDS_IteratorOfElements.obj : error LNK2001: unresolved external symbol __imp__wassert
2>SMDS_Mesh.obj : error LNK2001: unresolved external symbol __imp__wassert
2>SMDS_MeshElement.obj : error LNK2001: unresolved external symbol __imp__wassert
2>SMDS_QuadraticEdge.obj : error LNK2001: unresolved external symbol __imp__wassert
2>SMDS_Mesh.obj : error LNK2019: unresolved external symbol memset referenced in function «void __cdecl std::_Uninitialized_default_fill_n1<class SMDS_MeshNode const * *,unsigned __int64,class std::allocator<class SMDS_MeshNode const *> >(class SMDS_MeshNode const * *,unsigned __int64,struct std::_Wrap_alloc<class std::allocator<class SMDS_MeshNode const *> > &,struct std::integral_constant<bool,1>)» (??$_Uninitialized_default_fill_n1@PEAPEBVSMDS_MeshNode@@_KV?$allocator@PEBVSMDS_MeshNode@@@std@@@std@@YAXPEAPEBVSMDS_MeshNode@@_KAEAU?$_Wrap_alloc@V?$allocator@PEBVSMDS_MeshNode@@@std@@@0@U?$integral_constant@_N$00@0@@Z)
2>SMDS_PolygonalFaceOfNodes.obj : error LNK2001: unresolved external symbol memset
2>SMDS_QuadraticFaceOfNodes.obj : error LNK2001: unresolved external symbol memset
2>SMDS_QuadraticVolumeOfNodes.obj : error LNK2001: unresolved external symbol memset
2>SMDS_Mesh.obj : error LNK2019: unresolved external symbol __RTDynamicCast referenced in function «public: bool __cdecl SMDS_Mesh::ChangeElementNodes(class SMDS_MeshElement const *,class SMDS_MeshNode const * * const,int)» (?ChangeElementNodes@SMDS_Mesh@@QEAA_NPEBVSMDS_MeshElement@@QEAPEBVSMDS_MeshNode@@H@Z)
2>SMDS_VolumeTool.obj : error LNK2019: unresolved external symbol sqrt referenced in function «public: double __cdecl XYZ::Magnitude(void)» (?Magnitude@XYZ@@QEAANXZ)
2>MSVCRTD.lib(ehvecdtr.obj) : error LNK2019: unresolved external symbol terminate referenced in function «int __cdecl ArrayUnwindFilter(struct _EXCEPTION_POINTERS *)» (?ArrayUnwindFilter@@YAHPEAU_EXCEPTION_POINTERS@@@Z)
2>MSVCRTD.lib(utility_desktop.obj) : error LNK2001: unresolved external symbol terminate
2>MSVCRTD.lib(dll_dllmain.obj) : error LNK2001: unresolved external symbol __C_specific_handler
2>MSVCRTD.lib(ehvecdtr.obj) : error LNK2001: unresolved external symbol __C_specific_handler
2>MSVCRTD.lib(ehvecctr.obj) : error LNK2001: unresolved external symbol __C_specific_handler
2>MSVCRTD.lib(_error_.obj) : error LNK2001: unresolved external symbol __C_specific_handler
2>MSVCRTD.lib(utility.obj) : error LNK2001: unresolved external symbol __C_specific_handler
2>MSVCRTD.lib(new_scalar.obj) : error LNK2019: unresolved external symbol _callnewh referenced in function «void * __cdecl operator new(unsigned __int64)» (??2@YAPEAX_K@Z)
2>MSVCRTD.lib(new_scalar.obj) : error LNK2019: unresolved external symbol malloc referenced in function «void * __cdecl operator new(unsigned __int64)» (??2@YAPEAX_K@Z)
2>MSVCRTD.lib(delete_scalar.obj) : error LNK2019: unresolved external symbol _free_dbg referenced in function «void __cdecl operator delete(void *)» (??3@YAXPEAX@Z)
2>MSVCRTD.lib(_init_.obj) : error LNK2019: unresolved external symbol _CrtDbgReport referenced in function _CRT_RTC_INIT
2>MSVCRTD.lib(_init_.obj) : error LNK2019: unresolved external symbol _CrtDbgReportW referenced in function _CRT_RTC_INITW
2>MSVCRTD.lib(thread_safe_statics.obj) : error LNK2001: unresolved external symbol _CrtDbgReportW
2>MSVCRTD.lib(_error_.obj) : error LNK2019: unresolved external symbol __stdio_common_vsprintf_s referenced in function _vsprintf_s_l
2>MSVCRTD.lib(utility.obj) : error LNK2019: unresolved external symbol _seh_filter_dll referenced in function __scrt_dllmain_exception_filter
2>MSVCRTD.lib(utility.obj) : error LNK2019: unresolved external symbol _configure_narrow_argv referenced in function «public: static int __cdecl __scrt_narrow_argv_policy::configure_argv(void)» (?configure_argv@__scrt_narrow_argv_policy@@SAHXZ)
2>MSVCRTD.lib(utility.obj) : error LNK2019: unresolved external symbol _initialize_narrow_environment referenced in function __scrt_dllmain_after_initialize_c
2>MSVCRTD.lib(utility.obj) : error LNK2019: unresolved external symbol _initialize_onexit_table referenced in function __scrt_initialize_onexit_tables
2>MSVCRTD.lib(utility.obj) : error LNK2019: unresolved external symbol _register_onexit_function referenced in function _onexit
2>MSVCRTD.lib(utility.obj) : error LNK2019: unresolved external symbol _execute_onexit_table referenced in function __scrt_dllmain_uninitialize_c
2>MSVCRTD.lib(utility.obj) : error LNK2019: unresolved external symbol _crt_atexit referenced in function _onexit
2>MSVCRTD.lib(utility.obj) : error LNK2019: unresolved external symbol _crt_at_quick_exit referenced in function at_quick_exit
2>MSVCRTD.lib(utility.obj) : error LNK2019: unresolved external symbol _cexit referenced in function __scrt_dllmain_uninitialize_c
2>MSVCRTD.lib(thread_safe_statics.obj) : error LNK2019: unresolved external symbol __vcrt_InitializeCriticalSectionEx referenced in function «int __cdecl __scrt_initialize_thread_safe_statics(void)» (?__scrt_initialize_thread_safe_statics@@YAHXZ)
2>MSVCRTD.lib(dll_dllmain.obj) : error LNK2019: unresolved external symbol _initterm referenced in function «int __cdecl dllmain_crt_process_attach(struct HINSTANCE__ * const,void * const)» (?dllmain_crt_process_attach@@YAHQEAUHINSTANCE__@@QEAX@Z)
2>MSVCRTD.lib(dll_dllmain.obj) : error LNK2019: unresolved external symbol _initterm_e referenced in function «int __cdecl dllmain_crt_process_attach(struct HINSTANCE__ * const,void * const)» (?dllmain_crt_process_attach@@YAHQEAUHINSTANCE__@@QEAX@Z)
2>MSVCRTD.lib(throw_bad_alloc.obj) : error LNK2019: unresolved external symbol __std_exception_copy referenced in function «public: __cdecl std::exception::exception(class std::exception const &)» (??0exception@std@@QEAA@AEBV01@@Z)
2>MSVCRTD.lib(throw_bad_alloc.obj) : error LNK2019: unresolved external symbol __std_exception_destroy referenced in function «public: virtual __cdecl std::exception::~exception(void)» (??1exception@std@@UEAA@XZ)
2>MSVCRTD.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol _wmakepath_s referenced in function «int __cdecl GetPdbDllPathFromFilePath(wchar_t const *,wchar_t *,unsigned __int64)» (?GetPdbDllPathFromFilePath@@YAHPEB_WPEA_W_K@Z)
2>MSVCRTD.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol _wsplitpath_s referenced in function «int __cdecl GetPdbDllPathFromFilePath(wchar_t const *,wchar_t *,unsigned __int64)» (?GetPdbDllPathFromFilePath@@YAHPEB_WPEA_W_K@Z)
2>MSVCRTD.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol wcscpy_s referenced in function «int __cdecl GetPdbDllPathFromFilePath(wchar_t const *,wchar_t *,unsigned __int64)» (?GetPdbDllPathFromFilePath@@YAHPEB_WPEA_W_K@Z)
2>MSVCRTD.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol __vcrt_GetModuleFileNameW referenced in function «struct HINSTANCE__ * __cdecl GetPdbDll(void)» (?GetPdbDll@@YAPEAUHINSTANCE__@@XZ)
2>MSVCRTD.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol __vcrt_GetModuleHandleW referenced in function «struct HINSTANCE__ * __cdecl GetPdbDll(void)» (?GetPdbDll@@YAPEAUHINSTANCE__@@XZ)
2>MSVCRTD.lib(_pdblkup_.obj) : error LNK2019: unresolved external symbol __vcrt_LoadLibraryExW referenced in function «struct HINSTANCE__ * __cdecl GetPdbDll(void)» (?GetPdbDll@@YAPEAUHINSTANCE__@@XZ)
2>MSVCRTD.lib(tncleanup.obj) : error LNK2019: unresolved external symbol __std_type_info_destroy_list referenced in function «void __cdecl __scrt_uninitialize_type_info(void)» (?__scrt_uninitialize_type_info@@YAXXZ)
2>D:FreeCADBuildbinSMDS_d.dll : fatal error LNK1120: 41 unresolved externals
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========

Your linkage consumes libraries before the object files that refer to them

• You are trying to compile and link your program with the GCC toolchain.
• Your linkage specifies all of the necessary libraries and library search paths
• If libfoo depends on libbar, then your linkage correctly puts libfoo before libbar.
• Your linkage fails with undefined reference to something errors.
• But all the undefined somethings are declared in the header files you have
  #included and are in fact defined in the libraries that you are linking.

Examples are in C. They could equally well be C++

A minimal example involving a static library you built yourself

my_lib.c

#include "my_lib.h"
#include <stdio.h>

void hw(void)
{
    puts("Hello World");
}

my_lib.h

#ifndef MY_LIB_H
#define MT_LIB_H

extern void hw(void);

#endif

eg1.c

#include <my_lib.h>

int main()
{
    hw();
    return 0;
}

You build your static library:

$ gcc -c -o my_lib.o my_lib.c
$ ar rcs libmy_lib.a my_lib.o

You compile your program:

$ gcc -I. -c -o eg1.o eg1.c

You try to link it with libmy_lib.a and fail:

$ gcc -o eg1 -L. -lmy_lib eg1.o 
eg1.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status

The same result if you compile and link in one step, like:

$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
/tmp/ccQk1tvs.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status

A minimal example involving a shared system library, the compression library libz

eg2.c

#include <zlib.h>
#include <stdio.h>

int main()
{
    printf("%sn",zlibVersion());
    return 0;
}

Compile your program:

$ gcc -c -o eg2.o eg2.c

Try to link your program with libz and fail:

$ gcc -o eg2 -lz eg2.o 
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status

Same if you compile and link in one go:

$ gcc -o eg2 -I. -lz eg2.c
/tmp/ccxCiGn7.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status

And a variation on example 2 involving pkg-config:

$ gcc -o eg2 $(pkg-config --libs zlib) eg2.o 
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'

What are you doing wrong?

In the sequence of object files and libraries you want to link to make your
program, you are placing the libraries before the object files that refer to
them. You need to place the libraries after the object files that refer
to them.

Link example 1 correctly:

$ gcc -o eg1 eg1.o -L. -lmy_lib

Success:

$ ./eg1 
Hello World

Link example 2 correctly:

$ gcc -o eg2 eg2.o -lz

Success:

$ ./eg2 
1.2.8

Link the example 2 pkg-config variation correctly:

$ gcc -o eg2 eg2.o $(pkg-config --libs zlib) 
$ ./eg2
1.2.8

The explanation

Reading is optional from here on.

By default, a linkage command generated by GCC, on your distro,
consumes the files in the linkage from left to right in
commandline sequence. When it finds that a file refers to something
and does not contain a definition for it, to will search for a definition
in files further to the right. If it eventually finds a definition, the
reference is resolved. If any references remain unresolved at the end,
the linkage fails: the linker does not search backwards.

First, example 1, with static library my_lib.a

A static library is an indexed archive of object files. When the linker
finds -lmy_lib in the linkage sequence and figures out that this refers
to the static library ./libmy_lib.a, it wants to know whether your program
needs any of the object files in libmy_lib.a.

There is only object file in libmy_lib.a, namely my_lib.o, and there’s only one thing defined
in my_lib.o, namely the function hw.

The linker will decide that your program needs my_lib.o if and only if it already knows that
your program refers to hw, in one or more of the object files it has already
added to the program, and that none of the object files it has already added
contains a definition for hw.

If that is true, then the linker will extract a copy of my_lib.o from the library and
add it to your program. Then, your program contains a definition for hw, so
its references to hw are resolved.

When you try to link the program like:

$ gcc -o eg1 -L. -lmy_lib eg1.o

the linker has not added eg1.o to the program when it sees
-lmy_lib. Because at that point, it has not seen eg1.o.
Your program does not yet make any references to hw: it
does not yet make any references at all, because all the references it makes
are in eg1.o.

So the linker does not add my_lib.o to the program and has no further
use for libmy_lib.a.

Next, it finds eg1.o, and adds it to be program. An object file in the
linkage sequence is always added to the program. Now, the program makes
a reference to hw, and does not contain a definition of hw; but
there is nothing left in the linkage sequence that could provide the missing
definition. The reference to hw ends up unresolved, and the linkage fails.

Second, example 2, with shared library libz

A shared library isn’t an archive of object files or anything like it. It’s
much more like a program that doesn’t have a main function and
instead exposes multiple other symbols that it defines, so that other
programs can use them at runtime.

Many Linux distros today configure their GCC toolchain so that its language drivers (gcc,g++,gfortran etc)
instruct the system linker (ld) to link shared libraries on an as-needed basis.
You have got one of those distros.

This means that when the linker finds -lz in the linkage sequence, and figures out that this refers
to the shared library (say) /usr/lib/x86_64-linux-gnu/libz.so, it wants to know whether any references that it has added to your program that aren’t yet defined have definitions that are exported by libz

If that is true, then the linker will not copy any chunks out of libz and
add them to your program; instead, it will just doctor the code of your program
so that:-

• At runtime, the system program loader will load a copy of libz into the
  same process as your program whenever it loads a copy of your program, to run it.

• At runtime, whenever your program refers to something that is defined in
  libz, that reference uses the definition exported by the copy of libz in
  the same process.

Your program wants to refer to just one thing that has a definition exported by libz,
namely the function zlibVersion, which is referred to just once, in eg2.c.
If the linker adds that reference to your program, and then finds the definition
exported by libz, the reference is resolved

But when you try to link the program like:

gcc -o eg2 -lz eg2.o

the order of events is wrong in just the same way as with example 1.
At the point when the linker finds -lz, there are no references to anything
in the program: they are all in eg2.o, which has not yet been seen. So the
linker decides it has no use for libz. When it reaches eg2.o, adds it to the program,
and then has undefined reference to zlibVersion, the linkage sequence is finished;
that reference is unresolved, and the linkage fails.

Lastly, the pkg-config variation of example 2 has a now obvious explanation.
After shell-expansion:

gcc -o eg2 $(pkg-config --libs zlib) eg2.o

becomes:

gcc -o eg2 -lz eg2.o

which is just example 2 again.

I can reproduce the problem in example 1, but not in example 2

The linkage:

gcc -o eg2 -lz eg2.o

works just fine for you!

(Or: That linkage worked fine for you on, say, Fedora 23, but fails on Ubuntu 16.04)

That’s because the distro on which the linkage works is one of the ones that
does not configure its GCC toolchain to link shared libraries as-needed.

Back in the day, it was normal for unix-like systems to link static and shared
libraries by different rules. Static libraries in a linkage sequence were linked
on the as-needed basis explained in example 1, but shared libraries were linked unconditionally.

This behaviour is economical at linktime because the linker doesn’t have to ponder
whether a shared library is needed by the program: if it’s a shared library,
link it. And most libraries in most linkages are shared libraries. But there are disadvantages too:-

• It is uneconomical at runtime, because it can cause shared libraries to be
  loaded along with a program even if doesn’t need them.

• The different linkage rules for static and shared libraries can be confusing
  to inexpert programmers, who may not know whether -lfoo in their linkage
  is going to resolve to /some/where/libfoo.a or to /some/where/libfoo.so,
  and might not understand the difference between shared and static libraries
  anyway.

This trade-off has led to the schismatic situation today. Some distros have
changed their GCC linkage rules for shared libraries so that the as-needed
principle applies for all libraries. Some distros have stuck with the old
way.

Why do I still get this problem even if I compile-and-link at the same time?

If I just do:

$ gcc -o eg1 -I. -L. -lmy_lib eg1.c

surely gcc has to compile eg1.c first, and then link the resulting
object file with libmy_lib.a. So how can it not know that object file
is needed when it’s doing the linking?

Because compiling and linking with a single command does not change the
order of the linkage sequence.

When you run the command above, gcc figures out that you want compilation +
linkage. So behind the scenes, it generates a compilation command, and runs
it, then generates a linkage command, and runs it, as if you had run the
two commands:

$ gcc -I. -c -o eg1.o eg1.c
$ gcc -o eg1 -L. -lmy_lib eg1.o

So the linkage fails just as it does if you do run those two commands. The
only difference you notice in the failure is that gcc has generated a
temporary object file in the compile + link case, because you’re not telling it
to use eg1.o. We see:

/tmp/ccQk1tvs.o: In function `main'

instead of:

eg1.o: In function `main':

See also

The order in which interdependent linked libraries are specified is wrong

Putting interdependent libraries in the wrong order is just one way
in which you can get files that need definitions of things coming
later in the linkage than the files that provide the definitions. Putting libraries before the
object files that refer to them is another way of making the same mistake.

Здравствуйте, уважаемые форумчане!

Написал лабу в visual с++ 6.0 по предмету универа, компиляция проходит успешно, но при линковке выходят следующие ошибки:

Linking…
main.obj : error LNK2001: unresolved external symbol «public: __thiscall Group::~Group(void)» (??1Group@@QAE@XZ)
main.obj : error LNK2001: unresolved external symbol «public: class Person * __thiscall Group::FindPerson(char const *)» (?FindPerson@Group@@QAEPAVPerson@@PBD@Z)
main.obj : error LNK2001: unresolved external symbol «public: class Person * __thiscall Group::FindPerson(double)» (?FindPerson@Group@@QAEPAVPerson@@N@Z)
main.obj : error LNK2001: unresolved external symbol «class ostream & __cdecl operator<<(class ostream &,class Person const &)» (??6@YAAAVostream@@AAV0@ABVPerson@@@Z)
main.obj : error LNK2001: unresolved external symbol «public: class Person * __thiscall Group::FindPerson(int)» (?FindPerson@Group@@QAEPAVPerson@@H@Z)
main.obj : error LNK2001: unresolved external symbol «public: bool __thiscall Group::operator==(class Group const &)const » (??8Group@@QBE_NABV0@@Z)
main.obj : error LNK2001: unresolved external symbol «public: class Person & __thiscall Group::operator[](int)» (??AGroup@@QAEAAVPerson@@H@Z)
main.obj : error LNK2001: unresolved external symbol «public: unsigned int __thiscall Group::Size(void)const » (?Size@Group@@QBEIXZ)
main.obj : error LNK2001: unresolved external symbol «class ostream & __cdecl operator<<(class ostream &,class Group const &)» (??6@YAAAVostream@@AAV0@ABVGroup@@@Z)
main.obj : error LNK2001: unresolved external symbol «public: void __thiscall Group::PutPerson(int,class Person const &)» (?PutPerson@Group@@QAEXHABVPerson@@@Z)
main.obj : error LNK2001: unresolved external symbol «public: __thiscall Person::Person(int,char const *,int,double)» (??0Person@@QAE@HPBDHN@Z)
main.obj : error LNK2001: unresolved external symbol «public: __thiscall Group::Group(unsigned int)» (??0Group@@QAE@I@Z)
Debug/main.exe : fatal error LNK1120: 12 unresolved externals
Error executing link.exe.

main.exe — 13 error(s), 0 warning(s)

Погуглив и покопав различные форумы пришел к выводу. что не хватает библиотек, которые необходимо подгружать вручную в project settings. Однако в разных топиках форума пишут о подгружении различных библиотек. Пробовал, не помогает.

Так же пробовал использовать Use MFC in a Shared DLL — так же не помогает.

Помогите разобраться с ситуацией, может нужно сделать еще что-то дополнительно?? Заранее благодарен. Если необходимо выложу архив с написанным, может кто поможет слинковать.