Problem: getting a simple program using the libssh library to compile successfully without getting a linker error.
Program:
#include <iostream>
#define LIBSSH_STATIC 1
#include <libssh/libssh.h>
#include <stdlib.h>
void sftpSession()
{
ssh_session test_session = ssh_new();
if (!test_session) {
throw std::runtime_error("Could not create a session?!");
return;
}
ssh_free(test_session);
std::cout << "Session created & freed successfully." << std::endl;
}
int main(int argc, char **argv)
{
std::cout << "SFTP test program" << std::endl;
try {
sftpSession();
}
catch (const std::runtime_error &e) {
std::cout << "thrown: " << e.what() << std::endl;
}
return EXIT_SUCCESS;
}
Machine is 64-bit, running Windows. Using MinGW (via CodeBlocks) and the build log (edited slightly for readability) shows the compiler command as:
x86_64-w64-mingw32-g++.exe
-Wall -fexceptions -O2 -std=c++0x -g -m64 -Dmine_dev=1
-I"C:\Program Files\zlib\zlib-1.2.8-dll\include"
-I"C:\Program Files (x86)\libssh\libssh-0.6.5\include"
-c C:\Users\ ... \SFTP_testing\main.cpp
-o obj\Release\main.o
x86_64-w64-mingw32-g++.exe
-L"C:\Program Files (x86)\Ingres\IngresII\ingres\lib"
-o bin\Release\SFTP_testing.exe
obj\Release\main.o
-s
"C:\Program Files (x86)\libssh\libssh-0.6.5\lib\libssh.dll.a"
obj\Release\main.o: In function `sftpSession()':
C:/Users/ ... /SFTP_testing/main.cpp:9: undefined reference to `ssh_new'
C:/Users/ ... /SFTP_testing/main.cpp:14: undefined reference to `ssh_free'
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 2 second(s))
3 error(s), 0 warning(s) (0 minute(s), 2 second(s))
Things I have tried/investigated
I understand that the undefined reference to refers to the linker being able to find the declaration of the functions, but not their definitions.
The compiler is indeed finding the header file and the functions' definitions.
The header file does have the necessary extern "C" code, including the following:
#ifdef __cplusplus
extern "C" {
#endif
...
LIBSSH_API ssh_session ssh_new(void);
...
LIBSSH_API void ssh_free(ssh_session session);
...
#ifdef __cplusplus
}
#endif
The linker is sucessfully finding the library. (Checked via the ProcessMonitor program. It is definitely accessing the libssh.dll.a file.)
Using the nm utility I checked that the object code in libssh.dll.a did indeed contain references for ssh_new and ssh_free
Checked no confusion between 32-bit/64-bit issues: there are two versions of the pre-compiled library supplied. One is ...\libssh-0.6.5\bin\libssh.dll and the other is ...\libssh-0.6.5\lib\libssh.dll.a and the former gives me the following error: i386 architecture of input file 'C:\Program Files (x86)\libssh\libssh-0.6.5\bin\libssh.dll' is incompatible with i386:x86-64 output but the latter gives no such error, so I assume that the libssh.dll.a file is the correct library file to use.
Checked the advice given in this very similar question about libssh2 about the order of libraries linked, but here the call to g++ looks right as the libssh.dll.a argument is right at the end.
Checked the more general advice about linker errors too but could not find anything that seemed to be applicable.
Cleaned before rebuilding to avoid effects from "dead wood".
Tried other older versions of the library. Same error message.
Tried (unsuccessfully) to compile a newer version of libssh.
The libssh is not linked. The correct way to do this is to copy the libssh directory (which contains the headers) under the include directory of you Code Blocks installation. and copy the .dll.a file under the lib directory of your CodeBlocks installation.
Also delete the #define LIBSSH_STATIC 1 line if you are going to do it this way.
Related
I'm trying to use the GLFW library, but am having difficulty with compiling a simple program. I went to the GLFW website and download the latest release, then using "How to build & install GLFW 3 and use it in a Linux project" I built and installed it.
Here's my code:
#include <GLFW/glfw3.h>
#include <iostream>
using std::cout;
using std::endl;
void GLFW_error(int error, const char* description)
{
fputs(description, stderr);
}
void run()
{
cout << "pooch" << endl;
}
int main()
{
glfwSetErrorCallback(GLFW_error);
if (!glfwInit()) exit(EXIT_FAILURE);
run();
glfwTerminate();
return 0;
}
Using the command line:
bulletbill22#ROBOTRON ~/Desktop $ g++ -std=c++11 -lglfw source.cpp
yields
source.cpp:function main: error: undefined reference to 'glfwSetErrorCallback'
glfwSetErrorCallback is taken from their tutorial for "Setting an error callback".
Inclusion of -glfw3 results in /usr/bin/ld: error: cannot find -lglfw3
Even though everything seemed to be installed correctly, I suspect the problem may lie somewhere with the installation of the GLFW library because I'm not used to CMake and don't entirely understand how it works. I'm frustrated because the answer must be simple, but I'm not sure which keywords are really relevant when googling the problem; mostly the results are people who were incorrectly compiling with CMake, which I'm not compiling with in this case.
It seems that the directories for the glfw3.h header and libglfw3.so (and/or libglfw3.a) library are not in the default path.
You can check with by adding the -v option to the g++ options. Locate the directory where the glfw3.h header is found - call this $GLFW_INCDIR - it typically ends with .../GLFW. Locate the directory where the library is found - call this $GLFW_LIBDIR. Try:
g++ -std=c++11 -I$GLFW_INCDIR source.cpp -o pooch -L$GLFW_LIBDIR -lglfw3
If all the library dependencies are satisfied, this hopefully results in a program called pooch.
One other thing: GLFW3 is a C library, and the callback function arguments are expected to be C functions. So your callback should have 'C' linkage, i.e.,
extern "C" void GLFW_error(int error, const char* description) ...
Also, if you're having trouble with cmake, you may have ccmake installed. Try ccmake . in the top-level directory of the GLFW3 package for 'interactive' configuration.
This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Closed 8 years ago.
I was following http://lazyfoo.net/tutorials/SDL/01_hello_SDL/windows/codeblocks/index.php tutorial on how to use SDL with Code::Blocks since I've been having trouble with this in pretty much every damn IDE I've tried.
The tutorial is pretty straight forward, on step number 7 it states
"we have to tell the compiler to link against the libraries. Go under Linker Settings and paste -lmingw32 -lSDL2main -lSDL2". I did exactly that. Then it says that if you get a bunch of undefined reference errors, you messed up this step, I don't really see how it is possible for me to mess up this step, since it is a simple step.
I would really like to get started with this, while using MinGW and Code::Blocks.
Information that might help resolve this:
I have MinGW directory located in my C:
I have a folder SDL in my C: directory, within that folder I am linking the include and lib files from SDL to Code::BLocks by right clicking on project properties and adding the directories. This all seems to be working fine.Include Directory = C:\SDL\SDL2-2.0.3\x86_64-w64-mingw32\include\SDL2 Lib Directory = C:\SDL\SDL2-2.0.3\x86_64-w64-mingw32\lib
As stated above, on the Linker Setting -> Other Linker Options: I wrote -lmingw32 -lSDL2main -lSDL2, yet I get a bunch of reference errors. I don't know what to try, I have been searching online for hours, I even replaced SDL_platform.h because it was causing issues and the undefined references are still there.
Please help. This is the code I am using to check if SDL is working, it isn't.
#include "SDL.h"
#include <iostream>
#include <cstdio>
#include <Windows.h>
int main( int argc, char* argv[])
{
// Fire up SDL, this starts all subsystems; audio video etc.
if ( SDL_Init(SDL_INIT_EVERYTHING) < 0 ) {
fprintf(stderr, "Unable to init SDL: %s\n", SDL_GetError());
exit(1);
}
// Now Shut it down
atexit(SDL_Quit);
return 0;
}
These are the errors I am getting:
-------------- Build: Debug in TITLE (compiler: GNU GCC Compiler)---------------
mingw32-g++.exe -Wall -g -IC:\SDL\SDL2-2.0.3\x86_64-w64-mingw32\include\SDL2 -c C:\Users\Bryan\Desktop\CodeBlocks\TITLE\main.cpp -o obj\Debug\main.o
mingw32-g++.exe -LC:\SDL\SDL2-2.0.3\x86_64-w64-mingw32\lib -o bin\Debug\TITLE.exe obj\Debug\main.o -lmingw32 -lSDL2main -lSDL2
obj\Debug\main.o: In function `SDL_main':
C:/Users/Bryan/Desktop/CodeBlocks/TITLE/main.cpp:10: undefined reference to `SDL_Init'
C:/Users/Bryan/Desktop/CodeBlocks/TITLE/main.cpp:11: undefined reference to `SDL_GetError'
C:/Users/Bryan/Desktop/CodeBlocks/TITLE/main.cpp:15: undefined reference to `SDL_Quit'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/libmingw32.a(main.o): In function `main':
e:\p\giaw\src\pkg\mingwrt-4.0.3-1-mingw32-src\bld/../mingwrt-4.0.3-1-mingw32-src/src/libcrt/crt/main.c:91: undefined reference to `WinMain#16'
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 0 second(s))
4 error(s), 0 warning(s) (0 minute(s), 0 second(s))
You have created a Windows executable project. The wizard set the entry point to WinMain. Your code implements a command line program with main(int argc, char**argv) as entry point.
If you want to stay with the main you should create a new command line project and add you
source files to this project. Alternativly you could try to change the project type.
For the SDL errors you should check, that you use matching compiler and libraries (32 vs. 64 bit).
I am trying to load a .so file in my Qt application under Linux. That is working using the dlopen() and dlsym() for basic funcions. But I need to get multiple lists of string from the .so library, so I've tried to use a common .h file for both, but I can't access the object from the main app.
This is what I have so far:
extmodule.h
#include <list>
#include <string>
using namespace std;
class ExtModule
{
public:
ExtModule();
list<string> L2MACSource;
list<string> L2MACDest;
...
modulefile.cpp
#include "extmodule.h"
extern "C" ExtModule getCont() {
ExtModule modul;
modul.L2MACSource.push_back("...")
return modul;
}
extern "C" void hello()
{
cout << "hello" << endl;
}
main.cpp
#include "extmodule.h"
...
dlopen("...../modulefile.so", RTLD_LAZY);
...
typedef ExtModule(*loadedFunc)();
loadedFunc ext_get = (loadedFunc)dlsym(ext_mod, "getCont");
typedef void (*hello_t)();
hello_t hello = (hello_t)dlsym(ext_mod, "hello");
hello();
ExtModule modul = ext_get();
hello() function works flawlessly, but I am not able to get the ext_get() working (/external.so: undefined symbol: _ZN9ExtModuleC1Ev). I have to retrieve multiple lists from the .so library, but I don't know if that is the correct way. Also, as you've probably guessed, I am not particularly skilled programmer. Any suggestion will be highly appreciated.
Thank you for any help.
You probably need to compile and link your main program with the -rdynamic flag (to ask the linker to emit dynamic symbols, so that names from the main program are visible to plugins) e.g.
g++ -Wall -rdynamic -g main.cpp -o mainprog
perhaps some libraries and additional flags are missing above, e.g. for Qt
and your plugin with
g++ -Wall -shared -g -fPIC modulefile.cpp -o module.so
perhaps also additional flags are missing above, e.g. for Qt
In practice, Qt knows about plugins and qmake also has plugin support.
If using dlopen & dlsym you always should check for errors:
ext_mod = dlopen("...../modulefile.so", RTLD_LAZY);
if (!ext_mod) {
fprintf(stderr, "dlopen failure: %s\n", dlerror());
exit (EXIT_FAILURE); }
and also
hello_t hello = (hello_t)dlsym(ext_mod, "hello");
if (!hello) {
fprintf(stderr, "dlsym failure: %s\n", dlerror());
exit (EXIT_FAILURE); }
Read dlopen(3), Program Library HowTo, C++ dlopen mini howto, Drepper's paper: How To write Shared Libraries, the Advanced Linux Programming book.
BTW, you don't show all of your C++ code. Please ensure that you have the required constructors and destructors. Read about the rule of three (for old C++03) which becomes the rule of five in C++11.
You can use below command to generate your *.so file.
g++ -shared -fPIC -o {libname}.so -l{name of *.so file where definition of ExtModule} -L{path of module.}
I have a compile problem I can't figure out for OpenCV2.1 in c++.
Here is a simple test code I am trying to compile:
#include <iostream>
#include "cv.h"
using namespace std;
int main() {
cout << "Hello World" << endl; // prints !!!Hello World!!!
cv::Mat mtx;
return 0;
}
I a compile error with an undefined reference as follows
**** Build of configuration Debug for project CJMVideo ****
**** Internal Builder is used for build ****
g++ -IC:\OpenCV2.1\include\opencv -IC:\Program Files\Point Grey Research\FlyCapture2\include -O0 -g3 -Wall -c -fmessage-length=0 -osrc\CJMVideo.o ..\src\CJMVideo.cpp
g++ -LC:\OpenCV2.1\lib -LC:\Program Files\Point Grey Research\FlyCapture2\lib64 -Xlinker --enable-auto-import -oCJMVideo.exe src\CJMVideo.o -lcxcore210 -lcv210 -lhighgui210 -lml210 -lFlyCapture2
src\CJMVideo.o:C:/OpenCV2.1/include/opencv/cxmat.hpp:378: undefined reference to `cv::fastFree(void*)'
collect2: ld returned 1 exit status
Build error occurred, build is stopped
Time consumed: 1438 ms.
The error is C:/OpenCV2.1/include/opencv/cxmat.hpp:378: undefined reference to `cv::fastFree(void*)'
I believe I have compiled all the libraries correctly from the above command...What is the problem?
Thanks
Even though the message suggests it has not found that symbol on the OpenCV libraries, I must point out that from the command line pasted above, it seems you are trying to link your application against 64-bit compiled libraries, as indicated by -LC:\Program Files\Point Grey Research\FlyCapture2\lib64. That means you must compile OpenCV to be 64-bit too, or compile both to be 32 bits.
You are probably missing one library. On Windows, my OpenCV projects usually adds cv210.lib cvaux210.lib cxcore210.lib cxts210.lib highgui210.lib, but I use Visual Studio 2005 most of the times.
I have had problems linking cv::fastfree when the OpenCV lib was built with the intel TBB parallel library, building without TBB worked
Using MSYS, I compiled libpq (from compiling postgres). I then compiled libpqxx. Now, I want to create a client that will use libpqxx. libpq seemed to work fine. And, I can compile code with libpqxx. However, linking the libpq client application fails.
Here's my code:
#include <pqxx/pqxx>
#include <iostream>
using namespace std;
using namespace pqxx;
int main() {
connection Conn("dbname=test");
cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!!
return 0;
}
I added a bunch of libs to the link in a vain hope it would suddenly work. Here's what I have so far:
g++ -IC:\msys\1.0\local\pgsql\include -IC:\msys\1.0\local\include -O0 -g3 -Wall -c -fmessage-length=0 -osrc\Controller.o ..\src\Controller.cpp
g++ -LC:\MinGW\lib -LC:\msys\1.0\local\pgsql\lib -LC:\msys\1.0\local\lib -oController.exe src\Controller.o -lws2_32 -lole32 -lpqxx -lpq -loleaut32 -luuid
C:\msys\1.0\local\lib/libpqxx.a(connection_base.o): In function `ZN45_GLOBAL__N__ZN4pqxx16encrypt_passwordERKSsS1_7wait_fdEibP7timeval':
C:/msys/1.0/home/rsolomon/libpqxx/libpqxx-3.0.2/src/connection_base.cxx:1434: undefined reference to `select#20'
C:\msys\1.0\local\lib/libpqxx.a(connection_base.o): In function `ZN4pqxx15connection_base12check_resultERKNS_6resultE':
C:/msys/1.0/home/rsolomon/libpqxx/libpqxx-3.0.2/src/connection_base.cxx:420: undefined reference to `select#20'
collect2: ld returned 1 exit status
Build error occurred, build is stopped
Time consumed: 1770 ms.
I'm thinking the -lws2_32 should've gave me the "select#20". Why is the linker so uppity?
The Unix linker traditionally processes libraries from left to right. So it first considers ws2_32, finds that it has not much use, then goes on to pqxx, and sees that select is undefined and doesn't get defined by any of the later libraries. IOW, try moving ws2_32 to the end of the command line.