Mixing C and C++ causing exceptions to terminate - c++

I am porting a project from MSVC to mingw. The project contains C and C++. However, whenever an exception is thrown, instead of being caught, std::terminate gets called and the application crashes. I can't understand why so any advice would be appreciated.
My toolchain is cmake/ninja/mingw32 in a MSYS2 environment installed in Windows.
MCVE:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.6)
project(FailedExceptions)
add_executable(FailedExceptions c_funcs.c main.cpp)
//main.cpp
#include <iostream>
#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/xml_parser.hpp>
int main() {
try {
boost::property_tree::ptree pt;
std::printf("reading file\n");
boost::property_tree::read_xml("nonexistant-file", pt);
std::printf("provider file read\n");
} catch (...) {
std::printf("Exception caught\n");
}
return 0;
}
// c_funcs.c
int SomeCFunction()
{
return 0;
}
Output
$ cmake .. -GNinja
-- The C compiler identification is GNU 7.2.0
-- The CXX compiler identification is GNU 7.2.0
-- Check for working C compiler: C:/msys64/mingw32/bin/cc.exe -- works
-- Check for working CXX compiler: C:/msys64/mingw32/bin/c++.exe -- works
-- Configuring done
-- Generating done
-- Build files have been written to: C:/msys64/home/sferguson/src/vis/build
$ ninja -v
[1/3] C:\msys64\mingw32\bin\cc.exe -MD -MT c_funcs.c.obj -MF c_funcs.c.obj.d -o c_funcs.c.obj -c ../c_funcs.c
[2/3] C:\msys64\mingw32\bin\c++.exe -MD -MT main.cpp.obj -MF main.cpp.obj.d -o main.cpp.obj -c ../main.cpp
[3/3] C:\msys64\mingw32\bin\c++.exe c_funcs.c.obj main.cpp.obj -o FailedExceptions.exe -Wl,--major-image-version,0,--minor-image-version,0 -lgcc_eh -lgcc_eh -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
$ ./FailedExceptions.exe
reading file
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
$
Trace:
I can get this trace from Dr. Mingw. It really does appear that the crash happens between construction of the exception and the actual throw.
ntdll.dll!_NtTerminateProcess#8
ntdll.dll!_RtlExitUserProcess#4
kernel32.dll!_ExitProcessStub#4
msvcrt.dll!___crtExitProcess
msvcrt.dll!__cinit
msvcrt.dll!__exit
msvcrt.dll!_abort
FailedExceptions.exe!uw_init_context_1
FailedExceptions.exe!boost::property_tree::xml_parser::xml_parser_error::xml_parser_error
FailedExceptions.exe!boost::property_tree::xml_parser::read_xml<boost::property_tree::basic_ptree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >
FailedExceptions.exe!main
FailedExceptions.exe!__tmainCRTStartup [D:/develop/scripts/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtexe.c # 334]
kernel32.dll!#BaseThreadInitThunk#12
ntdll.dll!___RtlUserThreadStart#8
ntdll.dll!__RtlUserThreadStart#8
Troubleshooting:
I found some posts from 5-10 years ago suggesting that this could be a conflict between mingw's dw2 and sjlj libraries, but I only have the libgcc_s_dw2-1.dll binaries installed which come with the mingw-w64-i686-gcc-libs package in the msys pacman repository.
I tried changing my CMakeLists.txt file to compile everything with C++ with project(FailedExceptions LANGUAGES CXX). This prevents cmake from building my C files. So it does work for the MCVE, but my full project is missing all C content.
I've added set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -fexceptions) but it seems to have no effect. I've confirmed with ninja -v that this flag is added to the C-file compilation command.
As soon as I remove the C file from the build, everything works. But even though I'm not using the C-file in this MCVE, I still use it in my big project.
I've found another smaller example here. I can reproduce that problem IFF I also compile a C file in that same project.

It's a feature(bug?) in cmake implicit library detection introduced in cmake 3.1. CMake thinks that in C mode GCC needs to link with gcc_eh, which breaks C++ exception handling.
You can disable implicit library detection by adding this to CMakeLists.txt:
set(CMAKE_C_IMPLICIT_LINK_LIBRARIES "")
(Don't know how to exclude just gcc_eh from the list)

RustyX's answer is the accepted one, but I also found another number of work-arounds that seem to work:
set_source_files_properties(filename.c PROPERTIES LANGUAGE CXX)
set(CMAKE_C_COMPILER /path/to/cpp/compiler)
set(APPEND CMAKE_CXX_SOURCE_FILE_EXTENSIONS c).
But RustyX's is the best answer so far.
Edit: The last one doesn't work. It still builds with the C compiler. I'd also need to remove c from CMAKE_C_SOURCE_FILE_EXTENSIONS.

To add to rustyx answer above (I'm not allowed to comment), this is fixed in cmake 3.10 per this pull-request: https://gitlab.kitware.com/cmake/cmake/merge_requests/1460
I tested with CMake 3.10.2, and it seems like exceptions now work without having to specify the work-around cmake stanza rustyx is mentioning.

Related

Boost::Log Symbol not found for architecture on macOS

I really hate to ask this basic question, but I'm trying to build a system that uses websocketpp that will hopefully be deployed to an Ubuntu server at some point, and I want to use Boost Logging for the application. I figured since websocketpp already requires boost, i might as well use its logging.
I'm currently testing the setup on a mac, because that's all I have. My project is still only a main.cpp file, it follows this tutorial. it looks like this:
main.cpp
#include <iostream>
#include <boost/log/core.hpp>
#include <boost/log/trivial.hpp>
#include <boost/log/utility/setup/file.hpp>
#include <boost/log/expressions.hpp>
namespace logging = boost::log;
void init_logging(const char * logger_filename)
{
logging::add_file_log(logger_filename);
logging::core::get()->set_filter(logging::trivial::severity >= logging::trivial::info);
}
int main(int, char*[]) {
init_logging("titan_logger.log");
BOOST_LOG_TRIVIAL(trace) << "This is a trace severity message";
BOOST_LOG_TRIVIAL(debug) << "This is a debug severity message";
BOOST_LOG_TRIVIAL(info) << "This is an informational severity message";
BOOST_LOG_TRIVIAL(warning) << "This is a warning severity message";
BOOST_LOG_TRIVIAL(error) << "This is an error severity message";
BOOST_LOG_TRIVIAL(fatal) << "and this is a fatal severity message";
std::cin.get();
return 0;
}
I was following the tutorial successfully until I wanted to use the file logger. Then I started getting an error that ends like this:
...
traits<wchar_t>, std::__1::allocator<wchar_t> > >, boost::log::v2s_mt_posix::fallback_to_none>::operator()<boost::log::v2s_mt_posix::binder1st<boost::log::v2s_mt_posix::output_fun, boost::log::v2s_mt_posix::expressions::aux::stream_ref<boost::log::v2s_mt_posix::basic_formatting_ostream<char, std::__1::char_traits<char>, std::__1::allocator<char> > >&> >(boost::log::v2s_mt_posix::attribute_name const&, boost::log::v2s_mt_posix::attribute_value_set const&, boost::log::v2s_mt_posix::binder1st<boost::log::v2s_mt_posix::output_fun, boost::log::v2s_mt_posix::expressions::aux::stream_ref<boost::log::v2s_mt_posix::basic_formatting_ostream<char, std::__1::char_traits<char>, std::__1::allocator<char> > >&>) const in main.o
boost::log::v2s_mt_posix::value_extractor<boost::log::v2s_mt_posix::trivial::severity_level, boost::log::v2s_mt_posix::fallback_to_none, boost::log::v2s_mt_posix::trivial::tag::severity>::operator()(boost::log::v2s_mt_posix::attribute_name const&, boost::log::v2s_mt_posix::attribute_value_set const&) const in main.o
"boost::log::v2s_mt_posix::aux::once_block_sentry::enter_once_block() const", referenced from:
boost::log::v2s_mt_posix::aux::once_block_sentry::executed() const in main.o
"boost::log::v2s_mt_posix::core::get_logging_enabled() const", referenced from:
boost::log::v2s_mt_posix::record boost::log::v2s_mt_posix::sources::basic_composite_logger<char, boost::log::v2s_mt_posix::sources::severity_logger_mt<boost::log::v2s_mt_posix::trivial::severity_level>, boost::log::v2s_mt_posix::sources::multi_thread_model<boost::log::v2s_mt_posix::aux::light_rw_mutex>, boost::log::v2s_mt_posix::sources::features<boost::log::v2s_mt_posix::sources::severity<boost::log::v2s_mt_posix::trivial::severity_level> > >::open_record<boost::parameter::aux::tagged_argument_list_of_1<boost::parameter::aux::tagged_argument<boost::log::v2s_mt_posix::keywords::tag::severity, boost::log::v2s_mt_posix::trivial::severity_level const> > >(boost::parameter::aux::tagged_argument_list_of_1<boost::parameter::aux::tagged_argument<boost::log::v2s_mt_posix::keywords::tag::severity, boost::log::v2s_mt_posix::trivial::severity_level const> > const&) in main.o
ld: symbol(s) not found for architecture x86_64
My guess is that I'm using the boost library that I linked using a brew install boost I ran a few days ago. Now that I need the built boost libraries for Boost::Log, it's failing.
How I built boost
I built boost using this tutorial but with g++-10 and std=c++14
I downloaded boost_1_75_0 and put it in my project dir, then the full commands I ran (from the project dir) are:
cd boost_1_75_0
./bootstrap.sh
./b2 -link=static toolset=gcc cxxflags=-std=c++14 --build-dir=../build --with-log --with-regex --with-random --with-system --with-thread --with-filesystem --with-date_time
I followed the advice of this comment's second suggestions, and put all static libraries in their own folder called lib_boost. The application is called Titan so that's what that means in the command below.
make command:
g++ -Wall -I/Users/QuantumHoneybees/Desktop/Titan/Titan/boost_1_75_0 -std=c++14 -lpthread main.cpp -o titan -L./lib_boost -lboost_log_setup-mt -lboost_log-mt -lboost_filesystem-mt -lboost_thread-mt -lboost_system-mt
My Hunch
This SO thread seems to have the same issue but using cmake. The thing is though... i do have the thread library linked. I just don't think it's linked properly. I think that part of the problem is that i'm using static linking... I'm trying to optimize runtime, i don't really care about binary size. So I'm intentionally using static linking.
I think i'm not linking the libraries correctly... I'm not a complete newbie with C++, but I suck at linking errors... I really don't know what may be the issue here. Any help would be appreciated. Thanks.
Update: (not a clean solution though)
so it turns out there were a few issues:
Erased and unlinked homebrew installed version, that was causing some false negatives
I had to link to the statically compiled .a file
for the boost_log file directly.
I also had to rebuild Boost using clang and switch make to use it as well
Here is the final (very ugly) command:
clang++ -Wall -I/Users/QH/Desktop/Titan/Titan/boost_1_75_0 -std=c++14 -lpthread main.cpp -o titan -L/Users/QH/Desktop/Titan/Titan/boost_1_75_0/stage/lib -lboost_system -lboost_thread -lboost_thread -lboost_filesystem /Users/QH/Desktop/Titan/Titan/boost_1_75_0/stage/lib/libboost_log.a
It works but is shows a lot of warnings about the same boost::log::v2s_mt_posix:: methods as caused the errors, but I honestly don't care about fixing them at this point.
for some reason, if i replace that last library with -lboost_log i get the same undefined reference error again. I hope that helps someone with an answer!
For future travelers, here are the full set of working steps (thanks to #AndreySemashev:
Download the boost zip and cd into the directory, something like boost_1_75_0 (your version may be different)
run ./bootstrap.sh
run the following: ./b2 link=static cxxstd=14 --build-dir=../build --with-log --with-regex --with-random --with-system --with-thread --with-filesystem --with-date_time*
to compile, run clang++ -Wall -I./boost_1_75_0 -std=c++14 -lpthread main.cpp -o titan -L./boost_1_75_0/stage/lib -lboost_system -lboost_thread -lboost_thread -lboost_filesystem -lboost_log_setup -lboost_log
When you specify -lboost_log, the linker tries to find a shared library by default. Only if it isn't found, it looks for a static library.
In Boost.Log, symbols in static and shared libraries are mangled differently to make them incompatible. By default, the library assumes static linking. In order to enable dynamic linking, you must define BOOST_LOG_DYN_LINK or BOOST_ALL_DYN_LINK when compiling your code that uses Boost.Log (the former means that only Boost.Log is linked dynamically, the latter - that all Boost libraries are linked dynamically).
A few other notes:
You must ensure that the C++ standard library used to build Boost and your application match. For example, you cannot build Boost with libc++ and your code with libstdc++ - the two standard libraries define different symbols and have different ABIs, so your code won't link with Boost.
You must ensure that Boost is built with the same or higher C++ version than your code. Otherwise you may not be able to link because of missing symbols (e.g. methods involving C++11 features won't be available in C++03 Boost libraries).
You must ensure that ABI-affecting compiler options and macros are defined the same way when you build Boost and your code. Otherwise you may have ABI incompatibility issues, which are hard to diagnose and debug.
In b2 command line, -link=static should be specified without a dash, and you can use cxxstd=14 instead of cxxflags=-std=c++14.
If you're using Boost.Log features from boost/log/utility/setup directory, you may need to link with boost_log_setup library, in addition to boost_log. boost_log_setup depends on boost_log and provides additional library setup helpers.

Linking error in boost program_options

I'm trying to build a 3rd party C++ library from source, and it depends on Boost. In the very last step when building, I got errors like this:
[ 90%] Linking CXX executable Shannon_RNASeq_Cpp
CMakeFiles/Shannon_RNASeq_Cpp.dir/src/main.cpp.o: In function `command_line_for_find_rep(int, char**, Shannon_C_setting&,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&, std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >&)':
/home/lambda/Shannon_Cpp_RNA_seq/src/main.cpp:320: undefined reference to `boost::program_options::options_description::options_description(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int, unsigned int)'
I searched other questions on StackOverflow (e.g. Boost Program Options link error), and initially thought that it was caused by the different compilers used to build the non-header part of Boost, so I downloaded the source of Boost 1.68.0 and built it in my personal directory using the same compiler I used to build the 3rd party library (the compiler is gcc 8.2.0), and from the error message, I can tell that C++11 standard was used (you can see cxx11 in the error message), so it can't be the case that compiler not supporting C++11 is causing the trouble, as supposed previously (e.g. undefined reference to boost::program_options in xubuntu). To build Boost with a custom compiler (the default compiler of the server is terribly outdated), I followed the instructions here.
Some further search reveals that this is a linking problem. The 3rd party library must be built by CMake, and I followed the instruction in an answer to a previous question (How to link C++ program with Boost using CMake), by adding this line to CMakeLists.txt in the root directory of the 3rd party library:
target_link_libraries(Shannon_RNASeq_Cpp ${Boost_PROGRAM_OPTIONS_LIBRARY_RELEASE})
However, the same problem persists. I checked the file CMakeCache.txt, and confirmed that the desired compiler is used and Boost_PROGRAM_OPTIONS_LIBRARY_RELEASE points to the libboost_program_options.so in the directory where I put Boost 1.68.0 (the server has other older versions of Boost). I then used make VERBOSE=1 to check the bash commands invoked while building the library. The command doesn't sound wrong; the Boost program_options library has been linked; here's the command from make VERBOSE=1:
/usr/bin/cmake3 -E cmake_link_script CMakeFiles/Shannon_RNASeq_Cpp.dir/link.txt --verbose=1
It's referring to something in link.txt, and here's what I found there:
/home/lambda/mylibs/bin/c++ -g -rdynamic CMakeFiles/Shannon_RNASeq_Cpp.dir/src/main.cpp.o
CMakeFiles/Shannon_RNASeq_Cpp.dir/src/run_tasks.cpp.o -o
Shannon_RNASeq_Cpp lib_shannon/libmulti_graph_handler.a
lib_shannon/libcontig_graph_handler.a lib_shannon/libprimary_lib.a
-lboost_program_options lib_shannon/libsparse_flow_handler.a
-lglpk lib_shannon/libseq_graph_handler.a -lpthread
-lboost_system -Wl,-Bstatic -lmetis -Wl,-Bdynamic -lboost_filesystem
-lboost_program_options
So yes, Boost program_options has been linked (-lboost_program_options). I wonder if this is something wrong with program_options, since all errors that occurred at this stage are from program_options; I also linked to 2 other Boost compiled libraries, namely filesystem and system, and they do not appear in any error message I saw here.
I solved this problem myself (see my answer below), but new to CMake (and my only experiences with C++ is Rcpp), I don't know why it worked. Can someone please explain why switching to a static library worked? Also, when CMake linked to the default version of Boost on the server, it also by default used the .sos rather than the .as, even though the .as are available. Is there any way to tell CMake to use the .as rather than the .sos? Are there other solutions?
What I did was to change all the .sos in CMakeCache.txt into .as, like I changed libboost_program_options.so into libboost_program_options.a, and this error went away. Then the command from make VERBOSE=1 became:
/home/lambda/mylibs/bin/c++ -g -rdynamic CMakeFiles/Shannon_RNASeq_Cpp.dir/src/main.cpp.o
CMakeFiles/Shannon_RNASeq_Cpp.dir/src/run_tasks.cpp.o
-o Shannon_RNASeq_Cpp lib_shannon/libmulti_graph_handler.a
lib_shannon/libcontig_graph_handler.a lib_shannon/libprimary_lib.a
-Wl,-Bstatic -lboost_program_options lib_shannon/libsparse_flow_handler.a
-Wl,-Bdynamic -lglpk lib_shannon/libseq_graph_handler.a -lpthread
-Wl,-Bstatic -lboost_system -lmetis -lboost_filesystem -lboost_program_options -Wl,-Bdynamic

Static-linking of SDL2 libraries

I am using Windows 7, Code::Blocks and MinGW. I have little to no experience when it comes to compiling/building anything, especially when Code::Blocks doesn't use makefiles.
I downloaded SDL2-devel-2.0.0-mingw.tar.gz (SDL Development Libraries) from http://www.libsdl.org/tmp/download-2.0.php, and I'd like to create a standalone executable using SDL2 libraries, but so far I've always had to bundle the SDL2.dll file with the executable to make it work.
I've heard that I can not static-link dynamic libraries, so my only option seems to be doing something with the source files using the file SDL2-2.0.0.tar.gz (Source Code) from the link I mentioned above. However, I do not know what I should do with those.
What I managed to try with the source files is importing the Visual Studio project to Code::Blocks and building it, but it tells me "sdl-config No such file or directory" (I do not know what triggered that). I'm also not sure if building merely gives me an executable, with which I do not know what I can do to link it to my own executable.
A fool proof idiot's step by step guide would be the best bet to solve this case.
EDIT:
I managed to compile the SDL libraries with the guide Jonas provided, and got a libSDL2.a file.
At first I only added the path of libSDL2.a to "Link libraries:" -section of Code::Blocks, but I got a bunch of errors such as "SDL_Init() not declared in this scope".
In addition to the libSDL2.a path, I also added the path of SDL2-2.0.0\include to the Compiler's search directory as well as the path of SDL2-2.0.0\build.libs to the Linker's search directory. I also wrote this to my test file: #include "SDL.h". My test file now looks like this:
#include "SDL.h"
int main( int argc, char* args[] ) {
//Start SDL
SDL_Init( SDL_INIT_EVERYTHING );
//Quit SDL
SDL_Quit();
return 0;
}
It appears it did fix the declaration problem, but now Code::Blocks opened a SDL_mmjoystick.c file and gave me even more errors: "undefined reference to 'waveInClose#4'", "undefined reference to 'waveOutClose#4'", "undefined reference to 'joyGetNumDevs#0'" and tons of other ones.
Here's a screenshot of what's happening, note the different color of #include texts, I'm not sure why that happens: http://gyazo.com/00656a9c1e57a2bd0db1414fa7d68ced.png
I am not sure how to correctly take this library into use. Any help in this case, or should I make another question for it?
EDIT:
I added -lSDL2 to the linker options and deleted the other parameters. Now it builds fine:
mingw32-g++.exe -Wall -fexceptions -g -IC:\Users\User\Desktop\SDL2-2.0.0\include -c "C:\Users\User\Desktop\CppProjects\SDL project\main.cpp" -o obj\Debug\main.o
mingw32-g++.exe -Wall -fexceptions -g -IC:\Users\User\Desktop\SDL2-2.0.0\include -c "C:\Users\User\Desktop\CppProjects\SDL project\thetestfile.cpp" -o obj\Debug\thetestfile.o
mingw32-g++.exe -LC:\Users\User\Desktop\SDL2-2.0.0\build\.libs -o "bin\Debug\SDL project.exe" obj\Debug\main.o obj\Debug\thetestfile.o -lSDL2 ..\..\SDL2-2.0.0\build\.libs\libSDL2.a C:\Users\User\Desktop\SDL2-2.0.0\build\.libs\libSDL2.a -mwindows
Output size is 945.80 KB
Process terminated with status 0 (0 minutes, 1 seconds)
0 errors, 0 warnings (0 minutes, 1 seconds)
But when I try to run it, it says my computer lacks SDL2.dll, while the whole point was to static-link.
So currently I have the path to build/.libs in my Link libraries -settings, -lSDL2 in the Other linker options, and for search directories I have the path to SDL2-2.0.0/include for the compiler and SDL2-2.0.0/build/.libs for the linker.
In the build/.libs directory I can also see libSDL2.a, libSDL2.dll.a, libSDL2.la and libSDL2.lai files, which I don't know what they are.
It's not necessary to recompile the library,
SDL2 is given with static-link library named "libSDL2.a"
on the folder "SDL2-2.0.0\i686-w64-mingw32\lib\".
Just be sure to add these options to the linker :
"-lmingw32 -lSDL2main -lSDL2 -mwindows -lm -ldinput8 -ldxguid -ldxerr8 -luser32 -lgdi32 -lwinmm -limm32 -lole32 -loleaut32 -lshell32 -lversion -luuid -static-libgcc"
on Code:Blocks at "Project / Build Options... / Linket settings / Other linker options"
These options allow you to link with what SDL2.dll was using.
You can retreive them on the file "SDL2-2.0.0\i686-w64-mingw32\bin\sdl2-config"
The magical trick is to delete or rename the file "libSDL2.dll.a"
on the folder "SDL2-2.0.0\i686-w64-mingw32\lib\".
I added a "-" before to keep it in case I need it.
I don't know why this librairy overcomes the other and a clue would be appreciated.
I tried with Code::Blocks 12.11 MinGW32 and it worked.
If you run with some projects that use dynamic-link
and some other which use static-link, you will have to
keep your librairies in two different folders knowing that
"libSDL2main.a" will be in those two.
Sorry for my writing, I'm not used to write in english.
Mike

Cmake doesn't honour -D CMAKE_CXX_COMPILER=g++

I'm trying to force cmake to build my cpp code with g++, as by default it uses clang instead. So I use: cmake -D CMAKE_CXX_COMPILER=g++ ../src/CMakeLists.txt after which cmake checks for gcc and g++ (with success), but nonetheless make VERBOSE=1 yields
/usr/bin/c++ -o CMakeFiles/trial_cpp.dir/trial.cpp.o -c "/Users/Kuba/Code/Sketchpad/Trial project/src/trial.cpp"
Linking CXX executable trial_cpp
/opt/etlocal/bin/cmake -E cmake_link_script CMakeFiles/trial_cpp.dir/link.txt --verbose=1
/usr/bin/c++ -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/trial_cpp.dir/trial.cpp.o -o trial_cpp
As it calls /usr/bin/c++ not /usr/bin/g++ I concur it still uses clang. Any idea what's the problem? I know I have g++ and it's in /usr/bin/.
I'm running Mac OS X 10.8.2
CMAKE_CXX_COMPILER can only be set the first time cmake is run in a given build directory. On subsequent runs it is ignored. In order to change CMAKE_CXX_COMPILER you first need to delete the contents of the build directory and then run cmake again with that option.
Source: http://www.cmake.org/Wiki/CMake_Useful_Variables
I believe the reasoning for only using that variable on the first run is because changing it later would potentially invalidate everything already built including the configuration checks so cmake would have to start from scratch anyway.
I do it like this instead:
CXX=/usr/bin/g++ cmake ../src/CMakeLists.txt

Regex Boost library linking in release mode warns "duplicate section has different size" when using mingw-w64 toolchain

When linking my project in the release mode I am getting the following warning:
myProject-libs/release/libboost_regex-mt-s-1.50.0.a(cpp_regex_traits.o): duplicate section `.data$_ZZN5boost16cpp_regex_traitsIcE21get_catalog_name_instEvE6s_name[boost::cpp_regex_traits<char>::get_catalog_name_inst()::s_name]' has different size
I suspect that the cause could be that the boost library is compiled with different options than I use for my project, but I don't know how to find the difference (boost didn't output these options during the build).
In order to compile the boost for win32 on Ubuntu 12.04 I used this procedure:
tar jxf boost_1_50_0.tar.bz2
cd boost_1_50_0
./bootstrap.sh
echo "using gcc : 4.6 : i686-w64-mingw32-g++ : <rc>i686-w64-mingw32-windres <archiver>i686-w64-mingw32-ar ;" > user-config.jam
./bjam toolset=gcc target-os=windows --address-model=32 variant=release threading=multi threadapi=win32 link=static runtime-link=static --prefix=/opt/boost_1_50_0-release-static-windows-32 --user-config=user-config.jam -j 10 --without-mpi --without-python -sNO_BZIP2=1 -sNO_ZLIB=1 --layout=tagged install
In order to compile files in my project I use something like
i686-w64-mingw32-g++ -march=corei7 -mfpmath=sse -m32 -Wall -fmessage-length=0 -I"/opt/boost_1_50_0-release-static-windows-32/include" -std=c++0x -O3 -g0 -DNDEBUG -I"myProject/src/cpp" -c -o myProject/build/release/src/cpp/myproject.o myproject/src/cpp/myproject.cpp
The tests I have indicate that the regexps run fine but still I would like to resolve the warning.
EDIT
I found that additional options to the boost compiler can be added using a cxxflags= argument of bjam.
Example:
bjam cxxflags='-fPIC' ....
Maybe making sure to pass the same arguments as I do to the project could resolve the problem (particularly the arguments related to optimizations as suggested in the linked question).
Your compilers were compiled with different options :) Compiling the library on Linux and the program on Windows result in a situation where there is an identically named .data segment, but they aren't the same size. That could theoretically be interesting, inasmuch as a data segment is writable, but in practice, it shouldn't matter. Unless there is evidence to suggest this causes a problem of which I'm not aware, you can safely suppress that warning; I don't know how you'd make it go away, though.
I recently encountered this problem (i.e. linker warning "duplicate section has different size") when trying to compile boost for Windows using mingw.
The issue I had was that I compiled my application with -std=c++14 but when compiling boost I didn't specifically provide a dialect flag (which defaulted to -std=c++98 for g++ 5.3.0). Adding the dialect flag -std=c++14 when compiling boost solved the problem for me. See this answer for an explaination on how to set cxxflags when compiling boost.
I believe my solution might have worked for you (your application was compiled with -std=c++0x but boost was not provided any dialect flag). Although I am 6 years too late, I'll leave my answer here for others who happen to stumble-upon this issue.