MySQL Connector C++ "linker" error.

[realchamp]

Hello guys. Been working this for some time now, but I'm getting more and more confused.

When I use the MingW compiler on Windows, to compile my program:

#include <iostream>

#include <mysql_connection.h>
#include <mysql_driver.h>

using namespace std;

int main(){
sql::mysql::MySQL_Driver *driver;
sql::Connection	*con;

driver = sql::mysql::get_mysql_driver_instance();

con = driver->connect("tcp://127.0.0.1:3306", "root", " ");
cout << "connection OK";
cin.get();

delete con;

}

Using the following command:

g++ hw.cpp -o hw.exe

I get the following error:

C:\Users\kk\AppData\Local\Temp\ccRrhIs3.o:hw.cpp:(.text+0x7): undefined referen
ce to `_imp___ZN3sql5mysql19get_driver_instanceEv'
collect2: ld returned 1 exit status

I did a few attempts on how to link a libary, but it didn't work.

- realchamp.

[S_M_A]

If I remember correctly you use -l to link additional libraries (the letter l as in link that is, not I)

[realchamp]

If I remember correctly you use -l to link additional libraries (the letter l as in link that is, not I)

I did a link to mysqlcppconn.lib which were located insite the Connector C++ package, but nothing really happened.

-l mysqlcppconn.lib

[Cheezewizz]

it should be -lmysqlcppconn without the space. It might not be able to find the lib to link, you could try specifying the libs location by adding -L/c/path/to/lib.

[realchamp]

it should be -lmysqlcppconn without the space. It might not be able to find the lib to link, you could try specifying the libs location by adding -L/c/path/to/lib.

Thanks for your reply.

Unfortunately it still dont work.

This is were it wants the mysqlcppconn.lib in:

c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/

If I open my explorer and enter that path, it gives me

C:\MinGW\mingw32\bin

So I dropped the mysqlcppconn.lib in there and then compiled once agian and..

C:\MinGW\bin>g++ hw.cpp -lmysqlcppconn -o hw.exe
Info: løser std::cout  ved at lænke til __imp___ZSt4cout (automatisk import)
Info: løser std::cin  ved at lænke til __imp___ZSt3cin (automatisk import)
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: warning: a
uto-importing has been activated without --enable-auto-import specified on the c
ommand line.
This should work unless it involves constant data structures referencing symbols
 from auto-imported DLLs.
C:\Users\kk\AppData\Local\Temp\ccldRR4I.o:hw.cpp:(.text+0x7): undefined referen
ce to `_imp___ZN3sql5mysql19get_driver_instanceEv'
collect2: ld returned 1 exit status

And I've even put the mysqlcppconn.lib into multiple folders, to insure that it's in place!

[Cheezewizz]

where was the lib for mysqlconnector initially installed to? you don't have to move it you can just specify it's location on the command line. -l is for the addtional library names and then -L is for additional library locations...

[Lindley]

The -l flag is a bit strange. If you say "-lmylibrary", then you need to have libmylibrary.lib available. Note, not only is the extension ".lib" not included in the -l statement, but also the prefix "lib". At least, that's how gcc works in Linux (with .a or .so rather than .lib, though); I'm assuming it's the same for MinGW.

If the name of the library you are trying to link does not start with "lib", then you cannot use the -l flag. Instead, simply put the library name on the command line after the names of your source files.

[Cheezewizz]

that makes sense but then does it not normally complain about not being able to find a library named blah if you're trying to link it against the wrong name? Not only that but i've been using Mingw gcc port for a while and have used it like -ldxd9 -lwininet etc. and they've always been OK. if you google get_driver_instance, the first result points to another forum with others having similar problems and the solution, i think, was the location of the lib file...

[realchamp]

where was the lib for mysqlconnector initially installed to? you don't have to move it you can just specify it's location on the command line. -l is for the addtional library names and then -L is for additional library locations...

I think it's installed here: C:\Program Files (x86)\MySQL\Connector ODBC 5.1
Or here: C:\Program Files\MySQL\MySQL Connector C++ 1.0.5\lib\opt

The opt folder contains the mysqlcppconn.lib

The -l flag is a bit strange. If you say "-lmylibrary", then you need to have libmylibrary.lib available. Note, not only is the extension ".lib" not included in the -l statement, but also the prefix "lib". At least, that's how gcc works in Linux (with .a or .so rather than .lib, though); I'm assuming it's the same for MinGW.

If the name of the library you are trying to link does not start with "lib", then you cannot use the -l flag. Instead, simply put the library name on the command line after the names of your source files.

Can I just put that prefix on the file name? Also what do you mean with put the library on the command line?

Like:

g++ hw.cpp -o hw.exe mysqlcppconn.lib

that makes sense but then does it not normally conplain about not being able to find a library named blah if you're trying to link it against the wrong name? Not only that but i've been using Mingw gcc port for a while and have used it like -ldxd9 -lwininet etc. and they've always been OK. if you google get_driver_instance, the first result points to another forum with others having similar problems and the solution, i think, was the location of the lib file...

I will try to google that, thanks! Was it this that you refered to?:: http://forums.mysql.com/read.php?167...601#msg-299601

[Cheezewizz]

that's the one yep. I've just downloaded the lib and tried your code and end up with exactly the same issue. So I was wrong and it's obviously not a problem with not being able to locate the lib. It does however say somewhere on their site that "Binary incompatibilities can also occur if you are using a different C Run-Time Libraries (CRT) than we used for building" and i believe the prebuilt binaries were done with visual studio so maybe that's messing it up? could try grabbing the source and building your own binaries with mingw...

edit: er yeah i just tried one of the older binaries that they compiled with VS2005, and using VS2005 your test code compiles and links fine with it, so unfortunately it must be an issue with Mingw...

[realchamp]

that's the one yep. I've just downloaded the lib and tried your code and end up with exactly the same issue. So I was wrong and it's obviously not a problem with not being able to locate the lib. It does however say somewhere on their site that "Binary incompatibilities can also occur if you are using a different C Run-Time Libraries (CRT) than we used for building" and i believe the prebuilt binaries were done with visual studio so maybe that's messing it up? could try grabbing the source and building your own binaries with mingw...

edit: er yeah i just tried one of the older binaries that they compiled with VS2005, and using VS2005 your test code compiles and links fine with it, so unfortunately it must be an issue with Mingw...

Thanks for your reply. That just cleared up alot for me.

Should it work if I compiled it on Linux?

[Cheezewizz]

i don't see why not as long as you grab the right source for whatever distro you're using

[realchamp]

i don't see why not as long as you grab the right source for whatever distro you're using

I will go try compiling it on Linux. Thanks

[realchamp]

Linux attempt on Debian 5.0.

g++ hw.cpp -Llibmysqlcppconn.so.1.0.5 -o hw
/tmp/ccOXABZ5.o: In function `main':
hw.cpp:(.text+0x5e): undefined reference to `sql::mysql::get_mysql_driver_instance()'
collect2: ld returned 1 exit status
root@vs170144:~#

I'm seriously on the egde to give up.

[Cheezewizz]

Not having much luck with this are ya? thought about just using the C API directly instead? :P well the first thing to try (again) would be to make sure that it's definitely checking the right path for the shared library. check out this guy's post in another forum http://forums.mysql.com/read.php?167...772#msg-282772 and see if that works out...

Also will it make any difference that Debian isn't on this list? I used to occasionally struggle with getting stuff to work on there til I gave up and moved to Ubuntu...

Supported Platforms 
    Linux

    * FC4 (x86)
    * RHEL 3 (ia64, x86, x86_64)!
    * RHEL 4 (ia64, x86, x86_64)o
    * RHEL 5 (ia64*, x86, x86_64)o
    * SLES 9 (ia64, x86, x86_64)o
    * SLES 10 (ia64, x86_64)o
    * SuSE 11.0, (x86_64)
    * Ubuntu 8.04 (x86)
    * Ubuntu 8.10 (x86_64)