I'm trying to statically link to libcrypto.a (from the openssl library) after building it from source with a new toolchain. However whenever I try to use any of the functions from that library, I keep receiving "undefined reference" errors. I've made sure the right header file was included. I've also double checked the symbol table of libcrypto.a and made sure these functions are indeed defined.
Is there anything else I can do to debug this error- like getting more info out of the linker or examining libcrypto.a itself, to find out why the linker is spitting out "undefined reference" error when the indicted symbols shows up in the symbol table?
Undefined reference/symbol is a linker error indicating that the linker can't find the specified symbol in any of the object modules being linked. This indicates one or more of the following:
The specified class/method/function/variable/whatever is not defined anywhere in the project.
The symbol is inaccessible, probably due to an access specifier (in C++, doesn't apply to ANSI C)
The reference is incorrect. This can be due to a spelling error or similar problem. (unlikely)
You've neglected to include the required library in your build script when calling the linker.
I see your post is tagged c++. OpenSSL is written in C.
Did you remember to do
extern "C" {
#include <various SSL files>
}
?
grep the symbol out of libcrypto using nm
so you can see if its there - probably not (duh)
ssl has 2 libs , maybe you are using the wrong one
what exectly is the missing symbol
Related
im trying to build my first CMake project and it fails on CXX executable NeuralNetLibrary.
I get the undefined reference to FFLayer::test() error when building.
The full project is in here
https://github.com/JRazek/ConvolutionalNetLib.
Please help me how can I solve this issue.
The reason is that you're missing dependencies between the different library projects. For example, the Net library uses a function defined in FFLayer in Net.cpp, but the corresponding target_link_libraries(Net PRIVATE FFLayer) is missing.
This causes CMake to link against the static libraries in the wrong order, as it assumes that there are no order constraints.
If you fix that you'll find that you still get a missing symbol error for the destructor of Layer, which isn't implemented. You can add a .cpp file with the definition or just add = default; to the existing declaration, in both cases it will build.
The function RtlInitUnicodeString() used to initialize the UNICODE_STRING structure cannot be used as a linker error stating that an unresolved external symbol RtlInitUnicodeString referenced in function ***func_name*** (LNK2019) is thrown during compilation.
I tried using the statement #pragma comment(lib, "NtosKrnl.lib") to solve the issue at hand (as I assumed that linking the library mentioned here would resolve it) but a linker error stating the message cannot open file 'ntoskrnl.lib' (LNK1104) is thrown.
Thanks in advance.
The function cannot be called directly as they belong to the internal API and their mere prototype header is exposed via the winternl.h header file (at least in this case). In order to use the functions that are part of the internal API, one can either use run-time dynamic linking to link the Ntdll.dll library as stated here or link the library file ntdll.lib, which is a provided as a part of the WDK.
I am vainly trying to compile kmymoney using the emerge windows tool
all seems to go well until linking kmymoney
I get a huge number of unresolved references.
It appears the problem is that the libraries I am linking against are built without the windows specific "_imp__" on the exports but when I am compiling kmymoney the linker is expecting the "_imp__" + mangled name
For example the linker is looking for _imp___ZNK7KLocale28negativeMonetarySignPositionEv
but the export is called _ZNK7KLocale28negativeMonetarySignPositionEv
I assume I have to pass another flag or remove a flag from gcc to tell it to look for the correct export. but I am not sure how to do this. and cannot find the required documentation. even if I did I am not sure where to put it in the cmake file.
Any pointers would be greatly appreciated.
EDIT:
I have discovered that the libraries in fact do have the _imp__ prefix
it appears there is a missing underscore
when I grep for one of the missing functions I get the following
r:\lib>nm *.a | grep _ZNK7KLocale28negativeMonetarySignPositionEv
00000000 T __ZNK7KLocale28negativeMonetarySignPositionEv
00000000 I __imp___ZNK7KLocale28negativeMonetarySignPositionEv
Clearly the prefix is there. but it looks like its missing the first underscore
The prefix is __imp__ whereas the linker is looking for _imp__
Any ideas how I can resolve this??
I am receiving a lot of strange LNK2001 and LNK2019 errors when attempting to compile and link against a somewhat large static library (developed in-house). Here are the facts:
There are several static libs (most built in-house) all compiled into one large wrapper static lib for public consumption ("Pimpl" idiom). Essentially, we have libs A, B, and C all compiled into an internal/private lib called D. Then, we have an external/public lib that wraps around D called E.
The final product is not an executable, but a plug-in for Adobe Illustrator. Plug-ins are essentially just a DLL with a couple special resources and a special entry point (PluginMain() function). Compiling and linking works just great until I use the /INCLUDE option to specify that PluginMain should always be exported.
Creating a plug-in and linking against lib D works fine (no errors whatsoever). Creating a plug-in and linking against lib E gives over 100 unresolved symbol errors (symbols that should be present in E).
When I run DUMPBIN on the E.lib file, it appears to have all the symbols that the linker is complaining about when trying to create a plug-in. However, I'm not entirely certain I understand all the output syntax from DUMPBIN...
The libs are all cross-platform and compile and link just fine with GCC/LLVM on Mac.
Most of the functions that the linker complains about are either plain functions or static member functions. Most of those look suspiciously like functions that the compiler might try to inline. I have tried disabling optimization and/or automatic inlining, but the same link errors are still present.
Can anyone point me in the direction of some compile and/or link settings that might resolve the issue? Settings that are commonly misconfigured in situations like this?
Perhaps there is a setting I missed that is causing the linker not to export these symbols when linking E? Perhaps there is a setting that forces the linker to export ALL symbols when linking E that I can try? Maybe a utility exists to help me inspect the lib symbols myself for a clue?
I feel like I've tried everything, but it never hurts to ask. Thanks all.
EDIT 1: snowdude requested an actual link error:
E.lib(PathArt.cpp.obj) : error LNK2001: unresolved external symbol "private: __thiscall E::PathSegPoint::PathSegPoint(struct D::PathSegPoint const &)" (??0PathSegPoint#E##AAE#ABU0D###Z)
I should add that E::PathSegPoint::PathSegPoint(const D::PathSegPoint&) is a private constructor for constructing an external/public consumable E::PathSegPoint object from an internal/private D::PathSegPoint object. Again, this is the "Pimpl" idiom. Some classes/functions are friends of E::PathSegPoint to enable this sort of construction.
I thought I'd post an answer in case anyone shows up to this page in the future.
For several reasons a few years ago, we started compiling these libraries with the Intel C++ compiler inside Visual Studio. Some of these reasons have changed, and we needed to switch back to the MSVC compiler. Upon switching to the MSVC compiler, these linker errors disappeared!
I don't know why or how the Intel C++ compiler developed these link problems, but it's entirely possible that this is a bug.
Given a C++/GNU toolchain, what's a good method or tool or strategy to puzzle out linker errors?
Not sure exactly what you mean but if you are talking about cryptic linker symbols like:
mylib.so: undefined symbol: _ZN5CandyD2Ev
you can use c++filt to do the puzzling for you.
c++filt _ZN5CandyD2Ev
will return Candy::~Candy() so somehow Candy's destructor didn't get linked.
With gcc toolchain, I use:
nm: to find the symbols in object files
ld: to find how a library links
c++filt: to find the C++ name of a symbol from its mangled name
Check this for details.
Well the first thing would be RTFM. No, seriously, read the documentation.
If you don't want to do that, try a search on the error that comes up.
Here are a few other things to remember: "missing" symbols are often an indication that you haven't included the appropriate source or library; "missing" symbols are sometimes an indication that you're attempting to link a library created with a different mangling convention (or a different compiler); make sure that you have extern "C" where appropriate; declaring and defining aren't the same thing; if your compiler doesn't support "export" make sure your template code is available for when you instantiate objects.
Look at the names of the symbols that are reported to be problematic.
If there are missing symbols reported, find out in which source files or libraries those function/... should be defined in. Inspect the compilation/linker settings to find out why these files aren't compiled or linked.
If there are multiply defined symbols the linker usually mentions which object files or libraries contain them. Look at those files/their sources to find out why the offending functions/... are included in both of them.