Crypto++ causes undefined reference in Qt Creator, but not in code::blocks - linux

Nearly every function from Crypto++ produces undefined reference in Qt Creator, code::blocks however runs just great.
LIBS+= -lcryptopp
in .pro file seems to work as I can include needed files and declare variables unless constructor is overloaded.
For example
CryptoPP::Integer integer;
std::string str=CryptoPP::IntToString(integer, 10);
Throws
.../main.cpp:54: undefined reference to `std::string CryptoPP::IntToString<CryptoPP::Integer>(CryptoPP::Integer, unsigned int)'
collect2: error: ld returned 1 exit status
make: *** [PDBM] Error 1
07:10:21: The process "/usr/bin/make" exited with code 2.
cryptest.pro
Makefile
full rebuild //sorry, stackoverflow wants those links to be a code
/usr/lib/ contains libcrypto++.a, libcrypto++.so, libcryptopp.so and link to libcrypto++.a named libcryptopp.a
New findings: I have tried to compile this library before and now my project folder has all the .h and .cpp files in cryptopp folder. To provide all the code without showing the code new project has been created and more errors appeared:
In file included from /usr/include/cryptopp/secblock.h:7:0,
from /usr/include/cryptopp/integer.h:7,
from ../cryptest/main.cpp:7:
/usr/include/cryptopp/misc.h: In instantiation of ‘std::string CryptoPP::IntToString(T, unsigned int) [with T = CryptoPP::Integer; std::string = std::basic_string<char>]’:
../cryptest/main.cpp:54:54: required from here
/usr/include/cryptopp/misc.h:424:58: error: invalid cast from type ‘CryptoPP::Integer’ to type ‘char’
result = char((digit < 10 ? '0' : ('a' - 10)) + digit) + result;
^
Makefile:1113: recipe for target 'main.o' failed
Which means that cryptopp has been using those new .h files. So it is not only a problem with linker as I previously thought.
I'm on Ubuntu 16.04, using Qt 5.8 and Crypto++ from repository.

-lcryptopp
This option simply tells your linker that you want to link to a shared library called libcryptopp.so. However, it does not tell your linker where to find the shared library.
You must specify the folder which contains the developer's copy of the library, using the -L option. For example, if the library is in /usr/lib, then write this:
LIBS += -L/usr/lib/ -lcryptopp

Related

Visual C++ linker complaining about the absence of a symbol that is not absent

In short: on Visual C++ 2015, I get a linker error complaining about the absence of symbols that are present in the .lib file I link against.
In long: While compiling-and-liking some program from the command line with cl.exe I get the following as the first of many errors:
main.obj : error LNK2001: unresolved external symbol "protected: static struct wxEventTable const wxApp::sm_eventTable" (?sm_eventTable#wxApp##1UwxEventTable##B)
AFAIK, this long line says that my main.obj refers to a function to which a symbol ?sm_eventTable#wxApp##1UwxEventTable##B is associated, but that the linker could not find this symbol in the (long) list of libs that I provided on the command line.
I compile in /MD mode. Don't know if it helps, hurts, or has no importance here.
One of the files I link with is wxmsw31u_core.lib and doing
dumpbin /headers wxmsw31u_core.lib > here.txt
gives a long file containting the following
Version : 0
Machine : 8664 (x64)
TimeDateStamp: 56D46194 Mon Feb 29 16:19:48 2016
SizeOfData : 00000045
DLL name : wxmsw310u_core_vc140_x64.dll
Symbol name : ?sm_eventTable#wxApp##1UwxEventTable##B (protected: static struct wxEventTable const wxApp::sm_eventTable)
Type : data
Name type : name
Hint : 14083
Name : ?sm_eventTable#wxApp##1UwxEventTable##B
From this I infer that wxmsw31u_core.lib this is an "import library" : in other words that means that this lib does not contain the code but just refers to the dll file wxmsw310u_core_vc140_x64.dll that actually contains the code.
The latter wxmsw310u_core_vc140_x64.dll file indeed mentions ?sm_eventTable#wxApp##1UwxEventTable##B as I checked:
dumpbin /EXPORTS wxmsw310u_core_vc140_x64.dll > here2.txt
gave
14084 3703 0057F008 ?sm_eventTable#wxApp##1UwxEventTable##B = ?sm_eventTable#wxApp##1UwxEventTable##B (protected: static struct wxEventTable const wxApp::sm_eventTable)
I note that the first number is equal to the hint of the previous header plus one. I suppose this is normal?
I took the time to check the DLL as above but AFAIK, the DLL is not required in the linking process (it is required when you call the .exe that is produced).
All in all, it seems everything is there and it should link, so I am at a loss to determine what's wrong here.
Edit
I partially solved the problem by compiling myself the libary instead of using the compiled binaires for Windows provided by wxWidgets: I can now compile my program and all is well.
Well, not all: the initial question remains. I had a situation where I tried to link an obj with a lib to get an exe, the obj refers to a symbol whose mangled name is present verbatim in the lib, the linker does load the obj and lib (confirmed using /VERBOSE), yet the linker refuses to consider the symbol as "resolved". Why?
I'll create a new question where I'll ask for explanations about the conditions to be resolved.
AFAIK, this long line says that my main.obj refers to a function to which a symbol ?
Yes, linker is not able to find sm_eventTable#wxApp##1UwxEventTable##B on your paths specified.
Check that you have properly setup Additional Library Path parameter and that target platform of your application is /Machine:X64

Shared Library won't compile, *.a file missing

I'm trying to make a shared library, in Linux, which is a *.so. My DMD version is 2, latest. I'm just trying yo compile a simple empty shared library, with the code that Mono-D(plugin for MonoDevelop) creates. When I try to compile it, it tells me to check the build log, this is what's in the build log:
Building Solution: QScr (Debug)
Building: QScr (Debug)
Performing main compilation...
Current dictionary: /home/nafees/Desktop/Projects/QScr/QScr
dmd -debug -gc "myclass.d" "dllmain.d" "-I/usr/include/dmd" "-L/IMPLIB:/home/nafees/Desktop/Projects/QScr/QScr/bin/Debug/libQScr.a" "-odobj/Debug" "-of/home/nafees/Desktop/Projects/QScr/QScr/bin/Debug/libQScr.so" -w -vcolumns
/usr/bin/ld: cannot find /IMPLIB:/home/nafees/Desktop/Projects/QScr/QScr/bin/Debug/libQScr.a: No such file or directory
collect2: error: ld returned 1 exit status
--- errorlevel 1
Exit code 1
Build complete -- 1 error, 0 warnings
---------------------- Done ----------------------
Build: 1 error, 0 warnings
This is what dllmain contains:
module dllmain;
And in myclass.d:
module myclass;
class MyClass
{
//TODO: Enter class code here
}
export:
extern(D):
MyClass createMyClass()
{
return new MyClass();
}
I have no idea what is that a file, I'm still fairly new to D, and Linux.
How do I get it to compile? And could someone explain to me what is an .a file?
EDIT: No, it's not a duplicate, I'm trying to compile, while that question is about loading libraries.
EDIT2: I checked the directory, the .a file doesn't exist.
/usr/bin/ld: cannot find /IMPLIB:/home/nafees/Desktop/Projects/QScr/QScr/bin/Debug/libQScr.a: No such file or directory
/IMPLIB is a Windows linker switch. Your IDE is misconfigured (or just buggy).
Try changing the project settings in the IDE or filing a bug against the IDE.
Few things.
extern(D) would not be needed for free functions since it is default
You don't need createMyClass function at all, new will work fine
-shared must be passed to dmd for it to create a shared library
In case you didn't know, you will be passing the files in the shared library as import files when compiling the host binary.

Getting "undefined reference to" when using the lib for ARM, but not when compiling it

For one of my Qt Embedded projects I'm using a external Qt lib called SMTPEmail. This lib needs to be compiled before being included into a project, something that I managed to do successfully both for Qt 4.8 ARM and for Desktop.
The problem I'm getting is that when I include the headers into my project and include the library in the .pro, the linker gives me
(path_to_libs)/libSMTPEmail.so: undefined reference to `QSslSocket::connectToHostEncrypted(QString const&, unsigned short, QFlags<QIODevice::OpenModeFlag>)'
(path_to_libs)/libSMTPEmail.so: undefined reference to `QSslSocket::QSslSocket(QObject*)'
collect2: ld returned 1 exit status
make: *** [re8k_interface-tgt] Error 1
but only for compiling for ARM. IOW compiling the lib for both ARM and Desktop goes OK, compiling the project for Desktop using the lib goes OK but compiling it for ARM using the lib goes wrong.
Following this forum thread I suspected this could be due to missing the link to the library file of openssl (the project points to different lib folders when compiling for different environments). So I searched for all "openssl" related files inside the compiler for ARM (arm-arago-linux-gnueabi) and included in the same folder where the .so is located; same error. I then suspected the lib itself had other dependencies which were not in the path_to_libs, so I did a readelf -d libSMTPEmail.so and later in the .so.1 and readelf did return some lib dependencies that were not inside the same folder of the library. I then copied all such dependencies to the folder and got no success either.
So what could be happening? All dependencies known by me were put in place and I still get the error only for the situation where the lib is included by another project compiled for ARM.
You need to point your QMake where your libs and header file is in your .pro file;
So find where your library is assume /usr/local/include then ;
INCLUDEPATH += /usr/local/include
Add which libs you will use;
LIBS += -lSMTPEmail
You can check my answer here;
Two things stand out for me in your question:
1.
undefined reference to
This error message means that there was an error in the linking step of compilation. This occurs when you include a header to a function/class/variable but don't have the definition included in your own sources, or you do not link in a static library that does.
Searching for dependencies in libraries that are already compiled (.dll or .so) is too late, the compiler is looking for a static link, not a dynamic link.
2.
compiling the lib for both ARM and Desktop goes OK, compiling the
project for Desktop using the lib goes OK but compiling it for ARM
using the lib goes wrong.
This suggests that you are using conditional compilation in your .pro file that does a "both" compilation, a "desktop only" compilation and a "ARM only" compilation. If this is correct, you need to examine your compilation instructions for your "ARM only" compilation.
The error message itself refers to you using two functions from the QSslStock class. These are part of the QtNetwork module so you should have the following in your .pro file in order for the necessary links to be formed.
Qt += network

crt1.o: In function `_start': - undefined reference to `main' in Linux

I am porting an application from Solaris to Linux
The object files which are linked do not have a main() defined. But compilation and linking is done properly in Solaris and executable is generated. In Linux I get this error
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
My problem is, I cannot include new .c/.o files since its a huge application and has been running for years. How can I get rid of this error?
Code extractes of makefile:
RPCAPPN = api
LINK = cc
$(RPCAPPN)_server: $(RPCAPIOBJ)
$(LINK) -g $(RPCAPIOBJ) -o $(RPCAPPN)_server $(IDALIBS) $(LIBS) $(ORALIBS) $(COMMONLIB) $(LIBAPI) $(CCLIB) $(THREADLIB) $(DBSERVERLIB) $(ENCLIB)
Try adding -nostartfiles to your linker options, i.e.
$(LINK) -nostartfiles -g ...
From the gcc documentation:
-nostartfiles
Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib or -nodefaultlibs is used.
This causes crt1.o not to be linked (it's normally linked by default) - normally only used when you implement your own _start code.
-shared link option must be used when you compile a .so
The issue for me was, I by mistake put int main() in a namespace. Make sure don't do that otherwise you will get this annoying link error.
Hope this helps anyone :)
I had similar result when trying to build a new test project with boost, and it turned out that I was missing one declaration :
#define BOOST_TEST_MODULE <yourtestName>
I had this same problem when creating my c project, and I forgot to save my main.c file, so there was no main function.
I had a similar result when compiling a Fortran program that had C++ components linked in. In my case, CMake failed to detect that Fortran should be used for the final linking. The messages returned by make then ended with
[100%] Linking CXX executable myprogram
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
make[3]: *** [myprogram] Error 1
make[2]: *** [CMakeFiles/myprogram.dir/all] Error 2
make[1]: *** [CMakeFiles/myprogram.dir/rule] Error 2
make: *** [myprogram] Error 2
The solution was to add
set_target_properties(myprogram PROPERTIES LINKER_LANGUAGE Fortran)
to the CMakeLists.txt, so that make prints out:
[100%] Linking Fortran executable myprogram
[100%] Built target myprogram
I had the same issue with a large CMake project, after I moved some functions from one code file to another. I deleted the build folder, recreated it and rebuilt. Then it worked.
Generally, with suddenly appearing linker errors, try completely deleting your build folder and rebuilding first. That can save you the headaches from trying to hunt down an error that actually simply shouldn't be there: There might be CMake cache variables floating around that have the wrong values, or something was renamed and not deleted, ...
I had the same issue as to OP but on on FreeBSD 13.1.
What solved the issue was simply adding:
int main()
{
}
Since the .cpp file was only an object file containing definitions and declarations using:
extern "C"
{
<all definitions and declarations code goes here>
}
Every time I tried compiling this, the compiler kept throwing the same error as to OP.
So all I did was add an empty main() function all the way at the bottom and code compiled with no errors.

BUG - ProteaAudio with Lua does not work

Any idea why i cant use or cant build in Lua the ProTeaAudio ?
1) Exist
[root#example ~]# yum install lua-devel
Loaded plugins: presto, refresh-packagekit
Setting up Install Process
Package lua-devel-5.1.4-4.fc12.i686 already installed and latest version
Nothing to do
2) get failed to build the RtAudio
[sun#example proteaAudio_src_090204]$ make
g++ -O2 -Wall -DHAVE_GETTIMEOFDAY -D__LINUX_ALSA__ -Irtaudio -Irtaudio/include -I../lua/src -I../archive/baseCode/include -c rtaudio/RtAudio.cpp -o rtaudio/RtAudio.o
rtaudio/RtAudio.cpp:365: error: no ‘unsigned int RtApi::getStreamSampleRate()’ member function declared in class ‘RtApi’
rtaudio/RtAudio.cpp: In member function ‘virtual bool RtApiAlsa::probeDeviceOpen(unsigned int, RtApi::StreamMode, unsigned int, unsigned int, unsigned int, RtAudioFormat, unsigned int*, RtAudio::StreamOptions*)’:
rtaudio/RtAudio.cpp:5835: error: ‘RTAUDIO_SCHEDULE_REALTIME’ was not declared in this scope
rtaudio/RtAudio.cpp:5837: error: ‘struct RtAudio::StreamOptions’ has no member named ‘priority’
make: *** [rtaudio/RtAudio.o] Error 1
[sun#example proteaAudio_src_090204]$
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> require("proAudioRt");
stdin:1: module 'proAudioRt' not found:
no field package.preload['proAudioRt']
no file './proAudioRt.lua'
no file '/usr/share/lua/5.1/proAudioRt.lua'
no file '/usr/share/lua/5.1/proAudioRt/init.lua'
no file '/usr/lib/lua/5.1/proAudioRt.lua'
no file '/usr/lib/lua/5.1/proAudioRt/init.lua'
no file './proAudioRt.so'
no file '/usr/lib/lua/5.1/proAudioRt.so'
no file '/usr/lib/lua/5.1/loadall.so'
stack traceback:
[C]: in function 'require'
stdin:1: in main chunk
[C]: ?
Lua is trying to tell you that it cannot find an implementation of the module "proAudioRt" which it tried to find in a variety of places. The first block of places are various attempts at loading an implementation in Lua, then there are a few tries at various shared object files that might have contained the module. Since none of the places work, require fails.
None worked, because you haven't actually built a .so containing the module.
You need to get all of the compile and link errors to clear up so that you build proAudioRt.so. Note that for that to actually contain a Lua module, it must have a C callable entry point named luaopen_proAudioRt(), with the signature
LUALIB_API int luaopen_proAudioRt(lua_State *L);
That function is expected to construct the module's table, supplying it with members containing the functions of the module. The function luaL_register() is handy for this.
The Lua users wiki has a section on binding to Lua that should be helpful as well.

Resources