The actual error is a linker error. Undefined reference to get_driver_instance.
Any ideas what the problem is?
This is what I did to install.
Download and install MinGW to C:\MinGW. http://www.mingw.org/
Download boost and move the boost folder to C:\MinGW\include
Download Connector/C++ 1.1.3 http://dev.mysql.com/downloads/connector/cpp/
Move the mysql_connector/include/*.h (recursively) to C:\MinGW\include\
Move the mysql_connector/lib/mysqlcppconn-static.lib to C:\MinGW\lib\libmysqlcppconn-static.a
Move the mysql_connector/lib/mysqlconncpp.dll to C:\MinGW\lib\mysqlconncpp.dll
Alter cppconn/config.h to remove dupication
Copy the C++ example and name it test.cpp http://dev.mysql.com/doc/refman/5.1/en/connector-cpp-examples-complete-example-1.html
add "using namespace sql::mysql" to the file (as recommended)
run "g++ test.cpp -L C:\MinGW\lib -l mysqlcppconn-static"
It's likely in a namespace.
throw in this and see what happens:
using namespace sql::mysql;
edit: Also, did you look through the approximately 869 other times people have asked this same question on stack overflow before posting?
https://www.google.com/search?q=mysql+get_driver_instance+site:stackoverflow.com
If that isn't it, it can be a problem with c++ name mangling.
https://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_C.2B.2B
Because the name-mangling systems for such features are not standardized across compilers, few linkers can link object code that was produced by different compilers.
and I think the final answer is here:
http://www.mingw.org/wiki/MixingCompilers
another stack overflow answer saying this:
What problems can appear when using G++ compiled DLL (plugin) in VC++ compiled application?
You'll need to build the connector from source using your g++ compiler:
http://dev.mysql.com/doc/refman/5.1/en/connector-cpp-installation-source.html
Related
Sort briefing what I am trying to do:
I want to use vnode-lp on my windows PC. I’ve installed MinGW. I’ve installed the necessary dependencies like LAPACK & BLAS libraries as well as Profil/BIAS. The installation of all libraries passed the make and make install process without errors. I hope (!) I’ve managed to install it correctly.
Now the Problem:
Now I’ve tried to get a simple program compiled with basically northing in it just an #include “vnode.h”. First I tried it with Microsoft Visual Studio. Since this gave me several errors I tried to compile it with g++ using MinGW. This gives me the same errors. It starts with
./matrix.w:90:17: error: ‘v_bias’ is not a namespace-name
The Question:
How to include vnodelp into an c++ program and compile it without errors under windows, am I missing something?
Off-topic:
I am trying to get this running for over a week now and don’t know what to do anymore.
C++ is most definitely not C, and packages designed for C++ will never compile and run as C code. So, what you're trying to do really can't be done unless you do some fancy stuff by creating a .dll or something like that, and even then I think you wouldn't get the functionality you want. Why not write your code in C++ and compile with g++ or a similar compiler?
I have managed to finally solve this issue. In case someone has the same problem here is the solution.
I have missed something in the call. Here is the full call that has worked for me:
g++ -o2 –Wall –Wno-deprecated –DNDEBUG – DPROFIL_VNODE – DMAXORDER=50 –I(path to profil bias)/include –I(path to profil bias)/include/BIAS –I(path to profil bias)/src/Base –I(path to vnodelp)/FADBAD++ -I../include –DNDEBUG –c –o (filename).o (filename).cc
g++ -L(path to profil bias)/lib –L(path to lapack)/lib –L../lib –o (filename) (filename).o –lvnode –lProfil –lBias –llr (path to lapack)/lib/liblapack.lib (path to lapack)/lib/libblas.lib –lstd++
funfact:
This also complies with gcc instead of g++
Context: I'm using Qt 5.9.3 on Windows, building for MinGW 32-bit. The Qt part is a side issue though - the problem seems to be with MinGW. The version of MinGW is 4.3.0, supplied prebuilt as part of the Qt installation.
I'm building a library which talks to a USB device over HID. Everything compiles fine, but it fails at the link stage with
./..\..\object\debug\usb_hid_device.o: In function `ZN8MyApp3USB5Win3213getDevicePathB5cxx11Ell':
<MYPATH>/../../source/win32/usb_hid_device.cpp:99: undefined reference to `HidD_GetAttributes(void*, _HIDD_ATTRIBUTES*)#8'
./..\..\object\debug\usb_hid_device.o: In function `ZN8MyApp3USB5Win3214CHIDDeviceImplC2EllRNS_15LogPerComponentE':
<MYPATH>/../../source/win32/usb_hid_device.cpp:200: undefined reference to `HidD_FlushQueue(void*)#4'
The linker command is
g++ -shared -mthreads -Wl,-subsystem,windows -Wl,--out-implib,<MYPATH>\bin\debug\libusb_hid_comms.a -o <MYPATH>\bin\debug\usb_hid_comms.dll object_script.usb_hid_comms.Debug -lhid -lsetupapi -LC:\Qt\Qt5.9.3\5.9.3\mingw53_32\lib C:\Qt\Qt5.9.3\5.9.3\mingw53_32\lib\libQt5Guid.a C:\Qt\Qt5.9.3\5.9.3\mingw53_32\lib\libQt5Cored.a
If I omit -lhid I get the same errors. I also get the same errors if I remove -lhid and explicitly set the path and filename to libhid.a. If I deliberately mistype the path and filename, it comes up with an error, so I know the command-line is getting parsed correctly. But for whatever reason, MinGW appears to not be linking with one of its own library files.
I've also tried removing -lsetupapi and I get the linker errors I'd expect for the functions defined in there. Likewise the Qt library files. But it seems that specifically for libhid.a, MinGW can see the library file but just isn't going to link with it.
Has anyone else seen this? Or can anyone else with the same (or similar) version of MinGW confirm or deny that they can link with libhid.a? Or is there something obviously wrong with what I'm doing?
I've just found the answer. I'm posting an answer myself so that other people know in future, because I think this is still a valid question which people might want to know about.
The problem is the include file hidsdi.h. The majority of other header files which pull in Win32 API calls have extern "C" around the function declarations. However this one doesn't! The result is that we end up with C++ name mangling for linker symbols, instead of the C-style "_" in front of the linker symbols.
The solution is to use
extern "C"
{
#include <hidsdi.h>
}
and then everything works fine.
The version of hidsdi.h with the older version of MinGW (which I'm porting from) did have that protection around the function declarations. However it looks like it's gone in the newer version.
I try to get tests generated by the cxxtest framework working under a MinGW environment managed by mysys2. The tool generates C++ files with absolute paths. However, gcc seems to be unable to resolve this absolute paths.
Here is a minimal example to demonstrate the problem:
// file1.h
#include <iostream>
inline void hallo() { std::cout << "Hallo\n"; }
// main.cpp
#include "/home/phil/example/file1.h"
int main()
{
hallo();
return 0;
}
The file exists (at least the msys2 shell resolves the path):
$ ls /home/phil/example/file1.h
/home/phil/example/file1.h
... but calling g++ results in this error:
$ g++ main.cpp
main.cpp:1:38: fatal error: /home/phil/example/file1.h: No such file or directory
#include "/home/phil/example/file1.h"
^
compilation terminated.
Same error with clang.
Under a full Linux environment, the example works. It also works if I replace the absolute path by a relative one (#include "file1.h").
So, I assume the problem lies in the layer over Windows that is responsible to resolve paths. Not sure whether I should report it as a bug to the msys2 project, or whether it is a known problem. If it is a known problem, are there any workarounds (like setting -I options)?
(If possible, I would like to avoid replace the absolute paths, as they are in generated code by the cxxtest framework. Technically, running a postprocessing step on the generated files would be possible but seems like a hack in the long run.)
Since you are running compilers that use MinGW-w64 as their runtime environment, they don't recognize POSIX-style paths like that. I think they actually interpret the root directory "/" to be "C:\". Other than that, they would only recognize native Windows-style paths.
I recommend that you pass the argument -I/home/phil/example to your compiler from some program running in the msys-2.0.dll POSIX emulation runtime environment (e.g. /usr/bin/bash or /usr/bin/make). The msys-2.0.dll runtime will then convert that argument to use a native Windows path so the compiler can understand it, and statements like #include <file1.h> will work. Alternatively, you might try putting a Windows-style path in your source code, e.g. the path should start with C:\.
Note however that having absolute paths in source code or build scripts is a bad idea since it makes it harder to build the code on a different computer. You could consider using environment variables or relative paths.
Try using the MinGW compiler that Cygwin provides as a package. (In other words, forget the MSYS environment; work under Cygwin, but build the code as before, in the MinGW style.)
Then you should be able to have include references /home/phil; it will just resolve to C:\Cygwin\home\phil or wherever your Cygwin root is.
Actually, it might be possible under MSYS also (which, after all, is just the descendant of an old for of Cygwin). You just have to figure out what /home/phil is referring to, create that tree and work under there.
Whenever I try to compile this code it always ends up with this error:
In file included from /usr/include/wchar.h:6:0,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/cwchar:44,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/bits/postypes.h:40,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/iosfwd:40,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/ios:38,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/ostream:38,
from /usr/lib/gcc/i686-pc-cygwin/4.9.2/include/c++/iostream:39,
from test.cpp:1:
/usr/include/sys/reent.h:14:20: fatal error: stddef.h: No such file or directory
#include <stddef.h>
^
compilation terminated.
The code I was trying to compile is:
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World! :D";
return 0;
}
The error is because your gcc-core package and gcc-g++ are not of the same version. Either downgrade one of them to solve the problem or update both the libraries. Updating both the libraries is the recommended way.
I had this error on a fresh MinGW install, it had nothing to do with the installed packages mentioned in the current accepted answer by "Prasanth Karri". In my case the issue was caused by -nostdinc in my Makefile. I actually only needed that compiler flag when building for a different target platform (not when using MinGW) so I fixed the issue by removing that flag from MinGW builds.
When I was incorporating a software library written in C into an existing demo project(used a C++ mbed library) I encountered this problem. The demo project would compile just fine, but after I replaced the existing main file by my own, this error occurred.
At this point I hadn't yet thought about the fact that the mbed library that I needed was written in C++. My own main file was a .c file that #include the mbed header file. As a result I used my normal C source as if it was a C++ source. Therefore the compiler that was used to compile my main file was the C compiler.
This C compiler then encountered a #include of a module that actually does not exist (within its scope), as it's not a C++ compiler.
Only after I inspected the output of the build log I realised the various source C and C++ files were compiled by more that 1 compiler(the c++ compiler). The project used used compilers arm-none-eabi-c++ and arm-none-eabi-gcc (for embedded systems) as seen below.
Compile log:
Building file: ../anyfile.cpp
Invoking: MCU C++ Compiler
arm-none-eabi-c++ <A lot of arguments> "../anyfile.cpp"
Finished building: ../anyfile.cpp
Building file: ../main.c
Invoking: MCU C Compiler
arm-none-eabi-gcc <A lot of arguments> "../main.c"
In file included from <Project directory>\mbed/mbed.h:21:0,
from ../main.c:16:
<Project directory>\mbed/platform.h:25:19: fatal error: cstddef: No such file or directory
compilation terminated.
Of course in a C++ environment cstddef exists, but in a C environment cstddef doesn't exist, in stead it's just C's implementation of stddef.
In other words, cstddef does not exist in the C compiler.
I resolved this problem by renaming my main.c file to main.cpp and the rest of the code compiled smoothly too.
TLDR/Conclusion: When building a C++ project, avoid mixing C files with C++ files(sources and headers). If possible rename .c files to .cpp files to use the C++ compiler in stead of the C compiler where required.
In order to update it, follow below.
If you are on Windows, just run these on command prompt or powershell
Update the package list: mingw-get update
After updating the package list, run: mingw-get upgrade
Source: How to update GCC in MinGW on Windows?
This problem was solved for me as I installed codeblocks with mingw compiler then I copied the mingw folder from codeblocks to C drive and added
C\mingw\bin to the environment variables.
If you try to compile and see a message like, "fatal error: stddef.h: No such file or directory", the error is because your gcc-core and gcc-g++ packages are not of the same version. Rerun the Cygwin install and make sure that you select the highest numbered versions of gcc-core and gcc-g++.
After installing the C++ compiler with MinGW I encountered this problem as well. Apparently, you have to also install mingw32-base. Go to C:/MinGW/bin/mingw-get.exe (my path) and check it for installation at the Basic Setup tab.
I am porting a project from Windows to Linux/Ubuntu, which involves using open software called "PST SDK"
(http://pstsdk.codeplex.com) written in c++. This has not been updated since 2010 but it works fine in
Windows and supposedly works/did work in Linux. I set up a demo program with nothing more than including
the header files (the library is all headers, nothing to link). I had a lot of errors but got them
fixed by using g++ instead of gcc, and fiddling with the location of the library files and required
boost files.
However once I tried making some calls, I ran into problems. I got a few things working, but the
following code:
std::vector<pstsdk::folder> folderlist;
folderlist.push_back(folder);
causes this compile error:
error: 'pstsdk::property_bag& pstsdk::property_bag::operator=(const pstsdk::property_bag&)' is private
(There is a lot of other veribiage about what was instantiated from what file). Here is the compile command:
g++ -c -I/usr/local/include -Iboost_1_46_1 -Ipstsdk -I/usr/local/include/mysql ostdemo.cpp
It is specifically the push_back call causing the errors - take that out and they go away. Of course
that is critical to the working of my program. Any idea what this could be? I assume it has
something to do with my compiler version or switches, but I can't figure it out. I am not much of
a c++ programmer so any help would be appreciated.
Your vector::push_back() requires that the type is copy-assignable. Obviously, your pstsdk::folder is not copy-assignable due to the assignment operator being private.
What are the requirements for a type to be placed in a vector? It depends on whether you're using pre-C++11 or C++11, plus what operations you plan to do on these types. See here:
http://en.cppreference.com/w/cpp/container/vector
Pay attention to CopyAssignable, CopyConstructible, MoveAssignable and MoveConstructible
So the case of it working with Windows as opposed to Linux:
Remember that "Windows" and "Linux" are not C++ compilers. You need to expand on this and tell us what version of the g++ compiler you're using on each OS.