This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Closed 5 years ago.
I'm trying to get started with using mySQL C API for a project that I'm hoping to complete.
I've downloaded the mySQL Community Server version and the mySQL Connector/C from the official site.
Q1: Do I also need to download Connector/ODBC? What is the difference?
So, this is a basic program that I learnt and am trying to compile and link:
#include<stdio.h>
#include<mysql.h>
int main(int argc, char **argv)
{
printf("MySQL client version: %s\n", mysql_get_client_info());
exit(0);
}
I'm extremely confused as to what commands for compilation and linking I should use. When I do the following, this happens:
gcc mySQL.c -I/usr/local/mysql/include
Undefined symbols for architecture x86_64:
"_mysql_get_client_info", referenced from:
_main in mySQL-a3f748.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Can someone just help me out with this? I've struggled a lot and it all seems extremely confusing.
My question is about compiling and linking mySQL C API libraries and not the error.
The header file <mysql.h> only declares the functions and types needed. The actual function definition (its implementation) is in a library you need to link with.
You do that with the -l (lower-case L) option:
gcc mySQL.c -I/usr/local/mysql/include -lmysql
However, since you seem to have installed MySQL in a non-standard location, you might have to use the -L option to specify where the library is located (similar to the -I option):
gcc mySQL.c -I/usr/local/mysql/include -L/usr/local/mysql/lib -lmysql
This should at least make your program build. But there is still another issue that might come up if your MySQL library is not a static library but a dynamic library (i.e. a "DLL"), because the run-time loader will not know the location of the dynamic library. You need a special linker-flag for that too:
gcc mySQL.c -I/usr/local/mysql/include -L/usr/local/mysql/lib -lmysql -Wl,-rpath=usr/local/mysql/lib
Related
I'd like to build on this post, because my symptoms are identical, but the solution seems to be something else.
I am working in a Ubuntu container (Ubuntu 16.04.3 LTS), trying to compile a toy C program that will eventually connect to an SQL server. First things first: I have the latest libmysqlclient-dev installed:
root#1234:/home# apt install libmysqlclient-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libmysqlclient-dev is already the newest version (5.7.24-0ubuntu0.16.04.1).
0 upgraded, 0 newly installed, 0 to remove and 88 not upgraded.
root#1234:/home#
And when I look in the /usr/include/mysql directory, I see the critical header file I'll need:
root#1234:/home# ls -l /usr/include/mysql | grep mysql.h
-rw-r--r-- 1 root root 29207 Oct 4 05:48 /usr/include/mysql/mysql.h
root#1234:/home#
So far, so good. Now I found this little toy program from here:
#include <stdio.h>
#include "/usr/include/mysql/mysql.h"
int main() {
MYSQL mysql;
if(mysql_init(&mysql)==NULL) {
printf("\nInitialization error\n");
return 0;
}
mysql_real_connect(&mysql,"localhost","user","pass","dbname",0,NULL,0);
printf("Client version: %s",mysql_get_client_info());
printf("\nServer version: %s",mysql_get_server_info(&mysql));
mysql_close(&mysql);
return 1;
}
Now, following the advice of the previous post, I compile using the "-I" option to point to the mysql.h header file. (Yes, I am required to use GCC here):
root#1234:/home# gcc -I/usr/include/mysql sqlToy.c
/tmp/cc8c5JmT.o: In function `main':
sqlToy.c:(.text+0x25): undefined reference to `mysql_init'
sqlToy.c:(.text+0x69): undefined reference to `mysql_real_connect'
sqlToy.c:(.text+0x72): undefined reference to `mysql_get_client_info'
sqlToy.c:(.text+0x93): undefined reference to `mysql_get_server_info'
sqlToy.c:(.text+0xb4): undefined reference to `mysql_close'
collect2: error: ld returned 1 exit status
root#1234:/home#
Belly flop! The compiler has no idea what all the mySQL functions are, even though I've done all I can think of to point to that header file. As a sanity check, I made sure those mySQL functions are indeed in that header file; here's one as an example:
root#1234:/home# more /usr/include/mysql/mysql.h | grep mysql_init
libmysqlclient (exactly, mysql_server_init() is called by mysql_init() so
MYSQL * STDCALL mysql_init(MYSQL *mysql);
root#1234:/home#
So while I've pointed the compiler to the mysql.h header file in both my code AND with the "-I" option, it still has no clue what those 'mysql' functions are. The "-I" option was the solution in the previous post, but is not working for me here.
So... What might be the problem? I'm assuming this isn't a compiling problem, but maybe a linking one? In other words, I'm showing GCC where the mysql.h file is, but he is still not using it when processing the code?
Headers are not libraries. You are including the MySQL header during compilation, so these functions are defined, but you are not linking against the library which actually provides those functions.
These functions are provided by the libmysqlclient library, so you need to add the -lmysqlclient flag to your command line to fix this. (Note that this is a lower-case l, not an I.)
Additionally, since you are adding /usr/include/mysql to your system header path, you can include the library as
#include <mysql.h>
You do not need to -- and should not! -- specify the full path to the library in the #include directive.
I recently tried to build my https://github.com/eyalroz/cuda-api-wrappers/ library's examples after switching to another Linux distribution on the same machine. Strangely enough, I encountered a linking issue. The command:
/usr/bin/c++ -Wall -std=c++11 -g CMakeFiles/device_management.dir/examples/by_runtime_api_module/device_management.cpp.o -o examples/bin/device_management -rdynamic lib/libcuda-api-wrappers.a -Wl,-Bstatic -lcudart_static -Wl,-Bdynamic -lpthread -ldl -lrt
fails to find the CUDA runtime library, and I get:
CMakeFiles/device_management.dir/examples/by_runtime_api_module/device_management.cpp.o: In function `cuda::device::peer_to_peer::get_attribute(cudaDeviceP2PAttr, int, int)':
/home/eyalroz/src/mine/cuda-api-wrappers/src/cuda/api/device.hpp:38: undefined reference to `cudaDeviceGetP2PAttribute'
collect2: error: ld returned 1 exit status
but if I add -L/usr/local/cuda/lib64 it builds fine. This didn't use to happen before; and it doesn't happen on another machine I've checked on, nor does it even happen to other targets using the CUDA runtime in the same CMakeLists.txt (like version_managament).
FindCUDA seems to be finding everything, as the value of ${CUDA_LIBRARIES} is /usr/local/cuda/lib64/libcudart_static.a;-lpthread;dl;/usr/lib/x86_64-linux-gnu/librt.so. And the target lines in CMakeLists.txt are:
add_executable(device_management EXCLUDE_FROM_ALL examples/by_runtime_api_module/device_management.cpp)
target_link_libraries(device_management cuda-api-wrappers ${CUDA_LIBRARIES})
as is suggested in answers to other related questions (e.g. here). Why is this happening? Should I "manually" add the -L switch?
Edit: Following #RobertCrovella's suggestion, here are the ld search paths:
$ gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012 | tr ':' "\n" | tail -n +3
/usr/local/cuda/lib64/x86_64-linux-gnu/5/
/usr/local/cuda/lib64/x86_64-linux-gnu/
/usr/local/cuda/lib/
/usr/lib/gcc/x86_64-linux-gnu/5/
/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/5/
/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/
/usr/x86_64-linux-gnu/lib/
/usr/lib/x86_64-linux-gnu/5/
/usr/lib/x86_64-linux-gnu/
/usr/lib/
/lib/x86_64-linux-gnu/5/
/lib/x86_64-linux-gnu/
/lib/
/usr/lib/x86_64-linux-gnu/5/
/usr/lib/x86_64-linux-gnu/
/usr/lib/
/usr/local/cuda/lib64/
/usr/x86_64-linux-gnu/lib/
/usr/lib/
/lib/
/usr/lib/
$ ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu")
SEARCH_DIR("=/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib")
Notes:
Yes, I know the CMakeLists.txt there is ugly.
TL;DR:
After the FindCUDA invocation, add the lines:
get_filename_component(CUDA_LIBRARY_DIR ${CUDA_CUDART_LIBRARY} DIRECTORY)
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} "-L${CUDA_LIBRARY_DIR}")
and building should succeed on both systems.
Discussion:
(Paraphrasing #RobertCrovella and myself in the comments:)
OP was expecting, that if the following hold:
FindCUDA succeeds
${CUDA_LIBRARIES} includes a valid full path to either the static or the dynamic CUDA runtime library
the library dependency is indicated using target_link_libraries(relevant_target ${CUDA_LIBRARIES})
... then the CMake-based build he was attempting should succeed on a variety of valid CUDA installations. That is (unfortunately) not the case, since while FindCUDA does locate the CUDA library path, it does not actually make your linker search that path. So a failure should actually be expected. The build had worked on OP's old system due to a "fluke", or rather, due to OP having added the CUDA library directory to the linker's search path, somehow, apriori.
The linking command must be issued with the -L/path/to/cuda/libraries switch, so that the linker knows where to looks for the (unspecified-path) libraries referred to be the CUDA-related -l switches (in OP's case, -lcudart_static).
This answer discusses how to do that in CMake for different kinds of targets. You might also want to have a look at man gcc (the GCC manual page, also available here) regarding the -l and -L options, if you are not familiar with them.
If I try building the newest version of Caffe, it leads to this error:
$ make all
CXX/LD -o .build_release/tools/caffe.bin
clang: warning: argument unused during compilation: '-pthread'
Undefined symbols for architecture x86_64:
"caffe::Net<float>::Forward(float*)", referenced from:
test() in caffe.o
time() in caffe.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [.build_release/tools/caffe.bin] Error 1
I'm building on osx, OpenBLAS, and CPU_ONLY. I found a kind of similar issue on here but it appears to have been a resolved issue, and I'm not getting the exact same error, though perhaps it's related? I can also build and run an older version of Caffe from a month ago, so I think something has changed very recently.
Any ideas on how to overcome this error?
It shows a link problem when compile.On osx this problem will happen usually.I guess the problem happened in Makefile.config.You can change to
# To customize your choice of compiler, uncomment and set the following.
# N.B. the default for Linux is g++ and the default for OSX is clang++
CUSTOM_CXX := g++
and confirm some path is correct.
I had exactly the same problem. Its now resolved.
Do check if you already have a libcaffe.so in your system library paths (maybe /usr/local/lib). If so, delete the existing libcaffe.so and build again.
I am connecting the Mysql using c program in eclipse, I am using CYGWIN compiler to compile program. I have installed the mysql c connector and added the include files to the compiler and linker
but i am getting error
**** Build of configuration Debug for project DbConnectionC ****
make all
Building file: ../connection.c
Invoking: Cygwin C Compiler
gcc -I"C:\Program Files (x86)\MySQL\MySQL Connector C 6.0.2\include" -include"C:\Program Files (x86)\MySQL\MySQL Connector C 6.0.2\include\mysql.h" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"connection.d" -MT"connection.d" -o "connection.o" "../connection.c"
cygwin warning:
MS-DOS style path detected: D:\java\workspace\DbConnectionC\Debug
Preferred POSIX equivalent is: /cygdrive/d/java/workspace/DbConnectionC/Debug
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
../connection.c: In function `main':
../connection.c:57: warning: char format, different type arg (arg 2)
../connection.c:57: warning: char format, different type arg (arg 2)
../connection.c:61: warning: char format, different type arg (arg 2)
../connection.c:61: warning: char format, different type arg (arg 2)
Finished building: ../connection.c
Building target: DbConnectionC.exe
Invoking: Cygwin C Linker
gcc -L"C:\Program Files (x86)\MySQL\MySQL Connector C 6.0.2\lib\opt" -o "DbConnectionC.exe" ./connection.o -llibmysql.lib -lmysqlclient.lib
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -llibmysql.lib
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lmysqlclient.lib
collect2: ld returned 1 exit status
make: *** [DbConnectionC.exe] Error 1
makefile:29: recipe for target `DbConnectionC.exe' failed
**** Build Finished ****
Please help me on this
thanks in advance
In the first part you have some warnings about possible problems:
../connection.c:39: warning: implicit declaration of function `exit'
This means function exit() is not declared, your source needs an #include <stdlib.h>
../connection.c:46: warning: control reaches end of non-void function
You don't return a value at the end of main(), add a return 0; if the program succeeds.
In the second part are linker warnings:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -llibmysql.lib
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lmysqlclient.lib
which means the linker needs a path to the libraries or the libraries do not exist or the library names are misspelled.
One possible solution is using -lmysql -lmysqlclient instead of -llibmysql.lib -lmysqlclient.lib, but I'm not that familiar with Windows.
Having said that, I suggest strongly, you look at https://stackoverflow.com/tags/c/info and look at some book links.
I'm using MySQL 5.0.51a and I uncovered a bug which was causing an infinite loop (ending in a stack overflow and seqgfault) when my program was exiting.
I discovered that if I had a function called shutdown(), it would be called by during a call to mysql_close().
I've included a mimimal example C source file and makefile below to show the issue in action.
In the example, shutdown() gets called despite not being called by main().
What is going on here? Is my shutdown() clashing with a shutdown() in libmysqlclient?
If so, is there a reason gcc doesn't know about it?
I'm using gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
mysql_shutdown.c:
#include <stdio.h>
#include <mysql/mysql.h>
#define HOST "<hostname>"
#define USER "<username>"
#define PASSWD "<password>"
#define DB "<dbname>"
MYSQL *connection;
void shutdown(void)
{
printf("shutdown called\n");
}
int main()
{
connection = mysql_init(NULL);
mysql_real_connect(connection, HOST, USER, PASSWD, DB, 0, NULL, 0);
mysql_close(connection);
return 0;
}
makefile:
mysql_shutdown: mysql_shutdown.c
gcc -Wall -Wextra -Werror `mysql_config --cflags` -o $# $^ `mysql_config --libs`
Output:
$ ./mysql_shutdown
shutdown called
Note that this appears to be the opposite behaviour to that shown in GCC function name conflict. In that case the expected function wasn't being called, whereas in my case, a function is being called when it isn't expected.
What's most likely happening is that, because mysql_config --libs is giving you a list of the MySQL library files and the shutdown() function is in a different object file within the library(s), it's not being bought in.
You have to understand the way most linkers work. What they will do is tie together all the object files that you list explicitly and you end up with a partial executable and a list of symbols that have yet to be resolved.
Then the libraries are searched in an effort to resolve those symbols, by locating the object files within those libraries which can resolve the symbols. Normally what may happen is that you'll find mysql_close() in one of the libraries and load up its object file from that library. But that action may introduce more symbols that need resolving, which can in turn lead to more libraries being searched.
As an example, let's say mysql_close() calls shutdown() which is normally provided in one of the MySQL libraries. However, because you've already defined it, the loading of mysql_close() does not result in having an unresolved shutdown symbol. So there's no need to go looking for it in any of the libraries.
It does result in mysql_close() calling a totally different shutdown(), the one you provided in your code.