Error building and compiling GCC 5.2.0 from scratch on Vortex86DX - c++

In order to upgrade a VortexDX86 custom linux with a gcc 3.2.3 compiler, I´m trying to built the GCC 5.2.0 compiler to support the latest C++ 11 standard.
I have downloaded its source code from gcc.gnu.org and did the standard linux package builder based on this link.
$ mkdir ../gcc-build
$ cd ../gcc-build
$ ../gcc-5.2.0/configure --prefix=/usr --disable-multilib --with-system-zlib --enable-languages=c,c++
The configuration runs fine. The I do:
$ make
And I´m getting the following error:
make[3]: Entering directory `/home/ftp/pub/gcc-5.2.0/host-i586-pc-linux-gnu/gcc'
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../.././gcc -I../.././gcc/build -I../.././gcc/../include -I../.././gcc/../libcpp/include \
-o build/genmddeps.o ../.././gcc/genmddeps.c
cc1plus: warning: -Wmissing-format-attribute ignored without -Wformat
In file included from ../../gcc/genmddeps.c:19:
../../gcc/system.h:201:19: string: No such file or directory
../../gcc/system.h:218:22: algorithm: No such file or directory
../../gcc/system.h:219:20: cstring: No such file or directory
../../gcc/system.h:220:20: utility: No such file or directory
../../gcc/system.h:249:19: cstdlib: No such file or directory
make[3]: *** [build/genmddeps.o] Error 1
make[3]: Leaving directory `/home/ftp/pub/gcc-5.2.0/host-i586-pc-linux-gnu/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/ftp/pub/gcc-5.2.0'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/ftp/pub/gcc-5.2.0'
make: *** [all] Error 2
After that the make procedure aborts. I´ve installed all the dependencies (tcl, expect, dejagnu, perl, m4, gmp, mpfr and mpc) and I don´t know what is missing.
As said, the original Vortex linux has a gcc 3.2.3 compiler version.
I need to solve that but I don´t know where to start from. It seens to have confusion with the own gcc libraries....
Help appreciated to solve that.

You need a working C++ compiler to build recent releases of GCC, and you don't seem to have that (your GCC 3.2.3 seems to be missing the C++ standard library headers).
I suggest that you use the existing compiler to build GCC 4.7.4 (which can still be built by a C compiler) to get a working C++ compiler. Then use GCC 4.7.4 to build GCC 5.2

Bad. This did not solved the issue.... I´ve followed all the steps and the same error remains...
It happens maybe because you do not know enough your Operating System or maybe because you don't know to much about gcc
Here is step-by-step how to compile GCC-5.2.0 from scratches On Ubuntu.
1)
mkdir $HOME/gcc-5.2.0
2)
cd gcc-5.2.0/
3)
sudo apt-get install libmpfr-dev libgmp3-dev libmpc-dev flex bison gcc-multilib texinfo
4)
wget http://ftp.gnu.org/gnu/gcc/gcc-5.2.0/gcc-5.2.0.tar.gz
5)
tar -xzvf gcc-5.2.0.tar.gz
6)
cd gcc-5.2.0/
7)
mkdir build
8)
cd build/
9)
../configure --enable-multilib --disable-checking --enable-languages=c,c++ \
--enable-multiarch --enable-shared --enable-threads=posix \
--program-suffix=5.2 --with-gmp=/usr/local/lib --with-mpc=/usr/lib \
--with-mpfr=/usr/lib --without-included-gettext --with-system-zlib \
--with-tune=generic \
--prefix=$HOME/install/gcc-5.2.0
10)
make -j4
11)
make install

Related

( __ printf __ ) cannot be found in DLL (programfiles(x86)\codeblocks\mingw\bin\as.exe)

I'm trying to learn wxwidgets for cross platform GUI development, however I faced a problem.
When try to build wxwidgets with mingW32 I run into errors. I installed minGW32 with codeblocks 16.1 (works fine), added PATH to System Environment. Downloaded all possibilities from wxwidgets.org. None of them wants to compile when I try to compile wxwidgets library from cmd with mingw32. I go into wxwidgets/build/msw, typed several versions but to mention one:
mingw32-make -f makefile.gcc BUILD=release SHARED=1 MONOLITIC=1 UNICODE=1
(tried without shared, monolitic, even debug mode)
About the error:
( __ printf __ ) cannot be found in DLL
(programfiles(x86)\codeblocks\mingw\bin\as.exe)
I have the exe, tried to reinstall everything from scratch several times. I'm using Windows 10.
gcc -c -o gcc_mswudll\wxregex_regcomp.o -O2 -mthreads -DHAVE_W32API_H -DNDEBUG -I..\..\include -I..\..\lib\gcc_dll\mswu -D__WXMSW__ -D_UNICODE -MTgcc_mswudll\wxregex_regcomp.o -MFgcc_mswudll\wxregex_regcomp.o.d -MD -MP ../../src/regex/regcomp.c
makefile.gcc:5778: recipe for target 'gcc_mswudll\wxregex_regcomp.o' failed
mingw32-make: *** [gcc_mswudll\wxregex_regcomp.o] Error 1
Update:
After reinstalling and deleting everything connected to this, the problem has changed. The code I use, tried without the flag, and with flag but only"-std=gnu++11" too:
mingw32-make -f makefile.gcc SHARED=1 UNICODE=1 BUILD=release CXXFLAGS="-fno-keep-inline-dllexport -std=gnu++11"
The new error code:
gcc -c -o gcc_mswudll\wxregex_regcomp.o -O2 -mthreads -DHAVE_W32API_H -DNDEBUG -I..\..\include -I..\..\lib\gcc_dll\mswu -D__WXMSW__ -D_UNICODE -MTgcc_mswudll\wxregex_regcomp.o -MFgcc_mswudll\wxregex_regcomp.o.d -MD -MP ../../src/regex/regcomp.c
gcc: error: CreateProcess: No such file or directory
makefile.gcc:5702: recipe for target 'gcc_mswudll\wxregex_regcomp.o' failed
mingw32-make: *** [gcc_mswudll\wxregex_regcomp.o] Error 1
Any infos about the fact that I could not ever compile wxwidget with codeblocks' built in compiler? without addons?
Delete everything: wxWidgets, Code::Blocks and MinGW or TDM-GCC
* Download and install C::B, without MinGW or TDM
* Download TDM-GCC from here. If you install both 32 & 64 bits versions I suggest you to install them in two different folders.
* Download wxWidgets
Open a command window. Say you have TDM at "C:\TDM32" and wxWidgets at "C:\myWX".
Use these commands to compile wxWidgets:
PATH=%PATH%;C:\TDM32\bin
cd C:\myWX\build\msw
mingw32-make -f makefile.gcc BUILD=release SHARED=1 MONOLITIC=1 UNICODE=1
This should build an only .dll file with most of wxWidgets. Not OpenGL.
If you prefer several .dll don't use "Monolitic=1"
If you prefer not using wx'dlls, but static '.a' files added to your app, don't use "shared=1"
If you want to step into wxWidgets code when using a debugger, use "BUILD=debug"
If you want OpenGL use "USE_OPENGL=1"
To build wxWidgets with C++11 use CXXFLAGS="-std=gnu++11"
For your own app you must tell C::B:
* where the TDM compiler can be found
* where the wxWidgets headers can be found
* where the wxWidgets libraries (.dll or .a depending if you compiled with "shared") can be found

clang: warning: no such sysroot directory: '-mmacosx-version-min=10.5' on compiling LLVM (3.9.0)

I am compiling LLVM (3.9.0) using CMake (3.6.2) on my Mac (OsX) using GCC, but somehow I am getting the following error with following GCC configuration
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.3.0 (clang-703.0.31)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
[50%] Building C object projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.eprintf.dir/eprintf.c.o
clang: warning: no such sysroot directory: '-mmacosx-version-min=10.5'
/Users/Ritzy/llvm_src/llvm-3.9.0.src/projects/compiler-rt/lib/builtins/eprintf.c:14:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^
1 error generated.
make[2]: *** [projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.eprintf.dir/eprintf.c.o] Error 1
make[1]: *** [projects/compiler-rt/lib/builtins/CMakeFiles/clang_rt.eprintf.dir/all] Error 2
make: *** [all] Error 2
I am using following CMake command:
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_INSTALL_PREFIX=$INSTALL_DIR ..
cmake --build .
I spent hours figuring out what was wrong. Even tried to using gcc6 and clang but in vain.
Here's an example of what the command line flags supplied to a MacOS/X clang invocation might look like:
-pipe -stdlib=libc++ -std=c++11 -stdlib=libc++ -O2 -std=gnu++11 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.7 -Wall -W -fPIC $(DEFINES)
Note in particular this part:
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.7
-isysroot tells the compiler where to look for header files, and then the next argument -mmacosx-version-min=10.7 tells it what minimum version of MacOS/X to maintain backwards compatibility with.
In your case, your CMake invocation probably isn't specifying a value for the -isysroot argument, instead it probably has something like this:
-isysroot -mmacosx-version-min=10.5
... where the path that was intended to be supplied after the -isysroot flag has been left blank (i.e. an empty string) for some reason, and that is why "-mmacosx-version-min=10.5" is being interpreted as a path to look for header files in (which of course will not work).
As to why the path argument was left blank, that is something you'll have to investigate on your own.

Problems cross-compiling boost 1.57 from Linux to Windows

I'm trying to cross-compile boost 1.57 from 64-bit Debian Testing to 32-bit Windows.
Boost has cross-compile page, which doesn't really help much. For example, I had to google around and figure out that I need to explicitly disable bzip2 with -sNO_BZIP2=1 and zlib with nothing -- it will auto-disable it (previously you had to specify -sNO_ZLIB=1, but it has broke now).
So, after some trials and errors, I have come to:
$ i686-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.9-win32/lto-wrapper
Target: i686-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/lib/gcc-mingw-w64' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++ --enable-lto --with-plugin-ld --enable-threads=win32 --program-suffix=-win32 --program-prefix=i686-w64-mingw32- --target=i686-w64-mingw32 --with-as=/usr/bin/i686-w64-mingw32-as --with-ld=/usr/bin/i686-w64-mingw32-ld
Thread model: win32
gcc version 4.9.1 (GCC)
$ wget http://sourceforge.net/projects/boost/files/boost/1.57.0/boost_1_57_0.7z
$ ls
boost_1_57_0.7z
$ 7z x boost_1_57_0.7z
$ cd boost_1_57_0
$ echo "using gcc : : i686-w64-mingw32-g++ ;" > user-config.jam
$ ./bootstrap.sh
$ ./b2 -j10 --user-config=user-config.jam toolset=gcc-mingw address-model=32 binary-format=pe target-os=windows release --prefix=/usr/i686-w64-mingw32/local --without-python --without-wave -sNO_BZIP2=1
-j10 for 10 concurrent jobs, since I got 8 logical cpu cores.
address-model=32 for 32-bit build
binary-format=pe was suggested as workaround of the build failing in libs/context/src/asm/make_i386_sysv_elf_gas.S.
The above fails with:
gcc.compile.c++ bin.v2/libs/context/build/gcc-mingw-4.9.1/release/address-model-32/binary-format-pe/link-static/target-os-windows/threading-multi/unsupported.o
libs/context/src/unsupported.cpp:7:2: error: #error "platform not supported"
#error "platform not supported"
^
"i686-w64-mingw32-g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -m32 -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_SOURCE -DNDEBUG -I"." -c -o "bin.v2/libs/context/build/gcc-mingw-4.9.1/release/address-model-32/binary-format-pe/link-static/target-os-windows/threading-multi/unsupported.o" "libs/context/src/unsupported.cpp"
...failed gcc.compile.c++ bin.v2/libs/context/build/gcc-mingw-4.9.1/release/address-model-32/binary-format-pe/link-static/target-os-windows/threading-multi/unsupported.o...
...skipped <pbin.v2/libs/context/build/gcc-mingw-4.9.1/release/address-model-32/binary-format-pe/link-static/target-os-windows/threading-multi>libboost_context.a(clean) for lack of <pbin.v2/libs/context/build/gcc-mingw-4.9.1/release/address-model-32/binary-format-pe/link-static/target-os-windows/threading-multi>unsupported.o...
...skipped <pbin.v2/libs/context/build/gcc-mingw-4.9.1/release/address-model-32/binary-format-pe/link-static/target-os-windows/threading-multi>libboost_context.a for lack of <pbin.v2/libs/context/build/gcc-mingw-4.9.1/release/address-model-32/binary-format-pe/link-static/target-os-windows/threading-multi>unsupported.o...
...skipped <pstage/lib>libboost_context.a for lack of <pbin.v2/libs/context/build/gcc-mingw-4.9.1/release/address-model-32/binary-format-pe/link-static/target-os-windows/threading-multi>libboost_context.a...
...failed updating 1 target...
...skipped 3 targets...
At this point I have become stuck, I don't know how to fix this and google doesn't seem to help.
Got it to work by simply disabling failing libraries, which I happened to not need anyway
./b2 -j10 --user-config=user-config.jam toolset=gcc-mingw address-model=32 binary-format=pe target-os=windows release --prefix=/usr/i686-w64-mingw32/local --without-python --without-wave --without-context --without-coroutine --without-mpi --without-test --without-graph --without-graph_parallel -sNO_BZIP2=1
Actually, some of the disabled libraries might not be failing, I just went over the list of all libraries and disabled the ones which were totally unrelated to what I needed.
Of course that doesn't solve the issue of cross-compiling all of boost libraries to Windows, it would be nice to know how to do that correctly, but for now I'm content with that.

How to build pnacl toolchain

My goal is to make some new function to pnacl toolchain. Before I doing so, I think I should build the pnacl toolchain successfully first.
[11/04 Update]
Finally it works. Some package(bison, byacc, flex) I did't install and caused this problem.
[11/03 Update]
I use ubuntu-14.04.1-desktop-amd64 as my system
Also, ubuntu-12.04.5-desktop-amd64 is now testing [11/03 updated]
I've followed the step of the document all the way. Everything goes just fine until I run the toolchain_build_pnacl script
So I add the new error message here :
if I run the script using gcc to compile
toolchain_build/toolchain_build_pnacl.py --gcc --verbose --sync --clobber
--install toolchain/linux_x86/pnacl_newlib
then the following error message is
gcc -DHAVE_CONFIG_H -I. -I../../../src/binutils/gold
-I../../../src/binutils/gold -I../../../src/binutils/gold/../include - I../../../src/binutils/gold/../elfcpp -DLOCALEDIR="\"/share/locale\""
-DBINDIR="\"/bin\"" -DTOOLBINDIR="\"/arm-pc-nacl/bin\"" -DTOOLLIBDIR="\"/arm-pc-nacl/lib\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=yyscript.o -Wno-extended-offsetof -Wno-absolute-value -Wno-unused-function -Wno-unused-const-variable -Wno-unneeded-internal-declaration -Wno-unused-private-field -Wno-format-security -MT yyscript.o -MD -MP -MF .deps/yyscript.Tpo -c -o yyscript.o yyscript.c yyscript.c:1:1: error: return type defaults to ‘int’ [-Werror=return-type] yyscript.c:1:1: error: function
declaration isn’t a prototype [-Werror=strict-prototypes] cc1: error:
unrecognized command line option "-Wno-unused-private-field" [-Werror]
cc1: error: unrecognized command line option
"-Wno-unneeded-internal-declaration" [-Werror] cc1: error:
unrecognized command line option "-Wno-unused-const-variable"
[-Werror] cc1: error: unrecognized command line option
"-Wno-absolute-value" [-Werror] cc1: error: unrecognized command line
option "-Wno-extended-offsetof" [-Werror] cc1: all warnings being
treated as errors make[4]: *** [yyscript.o] Error 1
if I run it with default clang to compile
toolchain_build/toolchain_build_pnacl.py --verbose --clobber
--install toolchain/linux_x86/pnacl_newlib
then following error message is generated
/home/albaforia/SVN/nativeclient/third_party/llvm-build/Release+Asserts/bin/clang
-DHAVE_CONFIG_H -I. -I../../../src/binutils/gold -I../../../src/binutils/gold -I../../../src/binutils/gold/../include -I../../../src/binutils/gold/../elfcpp -DLOCALEDIR="\"/share/locale\"" -DBINDIR="\"/bin\"" -DTOOLBINDIR="\"/arm-pc-nacl/bin\"" -DTOOLLIBDIR="\"/arm-pc-nacl/lib\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=yyscript.o -Wno-extended-offsetof -Wno-absolute-value -Wno-unused-function -Wno-unused-const-variable -Wno-unneeded-internal-declaration -Wno-unused-private-field -Wno-format-security -MT yyscript.o -MD -MP -MF .deps/yyscript.Tpo -c -o yyscript.o yyscript.c yyscript.c:1:1: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int]
main() { return 0;
} ^~~~ 1 error generated. make[4]: *** [yyscript.o] Error 1
By default the PNaCl toolchain builds with a downloaded binary of clang because Google's automated builders run Ubuntu 12.04, and the gcc on those systems cannot build recent versions of LLVM. So there are 2 options:
If you used Chromium's depot_tools to get the Native Client sources, you can easily get a copy of the same compiler the builders use: from the parent directory of native_client run
tools/clang/scripts/update.sh which will download and install clang in the directory where toolchain_build_pnacl.py expects it. Once it is installed, it will be kept up to date automatically by Native Clients DEPS hooks if you use gclient from depot_tools.
Otherwise you can use the system gcc to compile the PNaCl toolchain using the --gcc option. This should definitely work on Ubuntu 14.04 as that the system we develop PNaCl on.
As an aside I've started another document that has a few more details on the build process (even if its focus isn't exactly what you are interested in) and of course there is the -h flag of toolchain_build_pnacl.py and its sources.
Could you post more information on what the error is? You probably need to scroll up a bit (the errors are interleaved with other parts of the build because it builds in parallel). To help debug this you could also run toolchain_build/toolchain_build_pnacl.py on specific targets and reduce the amount of building that goes on, e.g. you could do:
toolchain_build/toolchain_build_pnacl.py llvm_x86_64_linux --verbose --install toolchain/linux_x86/pnacl_newlib
FYI, when you re-run the toolchain_build/toolchain_build_pnacl.py script you don't need to re-specify --sync and --clobber.
You can also run the make command manually as you debug the issue. In any case we'd like to fix the issue you're running into!
To use system compiler instead of compiler from third_party/llvm_build/... you may want to pass the --gcc option to the build script. Though, it's still unlikely that you'll succeed in building toolchain under Ubuntu 14.04.
I'm using Ubuntu 14.04 and in order to build pnacl toolchain I have set up Ubuntu 12.04 chroot environment. Inside it I can successfully build the toolchain using the following commands:
# get sources for NaCl itself
gclient config http://src.chromium.org/native_client/trunk/src/native_client#13992 --name native_client
gclient sync -j16
cd native_client
# sync sources for binutils, llvm, etc.
toolchain_build/toolchain_build_pnacl.py --verbose --sync-only
# build and install toolchain
toolchain_build/toolchain_build_pnacl.py --verbose --gcc --install install_dir
PS: I mount /proc, /dev, /dev/pts, /sys, /run, /run/shm, /tmp into my chroot environment and everything runs smoothly. Without mounting some of these directories some build scripts may fail, though I'm not sure about it.

Error building application using Mysql connector

I have a problem with building a hello world application with MYSQL connector under c++.
Here is the build log:
"/usr/bin/make" -f nbproject/Makefile-Release.mk QMAKE= SUBPROJECTS= .build-conf
make[1]: Entering directory `/c/data/c++/MySqlConnectorHW'
"/usr/bin/make" -f nbproject/Makefile-Release.mk dist/Release/MinGW-Windows/mysqlconnectorhw.exe
make[2]: Entering directory `/c/data/c++/MySqlConnectorHW'
mkdir -p dist/Release/MinGW-Windows
g++.exe -v -d -v -L C:\Program Files\MySQL\MySQL Connector C++ 1.1.0\lib\opt\mysqlcppconn.dll -o dist/Release/MinGW-Windows/mysqlconnectorhw build/Release/MinGW-Windows/main.o -L/C/Program\ Files/MySQL/MySQL\ Connector\ C++\ 1.1.0/lib/opt -L/C/boost/libs -L/C/Program\ Files/MySQL/MySQL\ Connector\ C\ 6.0.2/lib/opt
g++.exe: Files\MySQL\MySQL: No such file or directory
g++.exe: Connector: No such file or directory
g++.exe: C++: No such file or directory
g++.exe: 1.1.0\lib\opt\mysqlcppconn.dll: No such file or directory
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\g++.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)
make[2]: Leaving directory `/c/data/c++/MySqlConnectorHW'
make[1]: Leaving directory `/c/data/c++/MySqlConnectorHW'
make[2]: *** [dist/Release/MinGW-Windows/mysqlconnectorhw.exe] Error 1
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
BUILD FAILED (exit value 2, total time: 21s)
Can someone help me with this issue? Thanks.
I've only used g++ under Unix, so some of this is based around the example you've given (and may be wrong).
You have several problems. You're getting some weird behaviour from g++ because it is treating this C:\Program Files\MySQL\MySQL Connector C++ 1.1.0\lib\opt\mysqlcppconn.dll as different arguments (seperated by space) C:\Program, Files\MySQL\MySQL, Connector, C++ and 1.1.0\lib\opt\mysqlcppconn.dll. This could be overcome by quoting the string "C:\Program Files\MySQL\MySQL Connector C++ 1.1.0\lib\opt\mysqlcppconn.dll".
However, the -L parameter passed to g++ is used to specify the search paths for libraries, so I wouldn't expect you to specify the name of the dll at this point. I'd expect you to pass -L"C:\Program Files\MySQL\MySQL Connector C++ 1.1.0\lib\opt". Based on your similar -L arguments, it would also appear that it's possible to achieve this by escaping codes in the string,, in which case you end up with: -L/C/Program\ Files/MySQL/MySQL\ Connector\ C++\ 1.1.0/lib/opt, which as it happens you're already passing.
Conclusion:, it seems likely that this: -L C:\Program Files\MySQL\MySQL Connector C++ 1.1.0\lib\opt\mysqlcppconn.dll is really supposed to be specifying a library to link with, not a search path. If this is the case, then you should be using -l, not -L it should simply be: -lmysqlcppconn (at least that's how it would work in Unix, under windows you may need to specify an extension i.e. -lmsqlcppcon.lib).
g++ will then try to resolve missing links by searching in all of the paths specified by -L parameters, to see if they have any libraries matching the supplied -l parameter.
I would suggest opening up the makefile: nbproject/Makefile-Release.mk and having a look to see where this parameter is coming from and update it accordingly.
Looking at the rest of your parameters, it's worth noting that you may have a similar problem when it gets to your output, since it also has a space in it that doesn't appear to be escaped:
-o dist/Release/MinGW-Windows/mysqlconnectorhw build/Release/MinGW-Windows/main.o
Several comments can be found on the internet of how to link the binary version of mysql-connector with your own code: http://dev.mysql.com/doc/refman/5.0/en/building-clients.html
A different route would be to build the source code of mysql-connector-c and mysql-connector-c++. The official version does not support MinGW as a target. However, the following post includes a link to adapted code versions for MinGW: http://forums.mysql.com/read.php?117,425191,425191#msg-425191