I've been using NetBeans for quite some time as a GUI based IDE for building C++ projects. Recently,
the project has been migrated over to Apache for management. In the transition time frame,
NetBeans has progressed from 8.2 to 9.0 to the current 10.0 incarnation. The 8.2 version was the last
which had an integral C++ development environment.
Via jumping through a few hoops, it is possible to run the c++ development environment in v10.0. The draw back is that
what ever was available in 8.2 remains as 'current'. Which means the build environment is
stuck at C++13.
By finding a development/beta version of 8.2 , I was able to obtain C++17 capability, but at a cost
of stability of the IDE. Development of this branch has been discontinued since, I think, early 2018. I do not
know if any behind-the-scenes work is happening somewhere.
So... it is time to try something else. Prior to NetBeans, I had been using Eclipse as an IDE. But, way back then, I had switched to
NetBeans as Eclipse appeared to be lagging and unstable. The tables have turned. Eclipse appears to be
progressing well now as a C++ IDE, far surpassing NetBean's capability.
For building, NetBeans generated makefiles directly. Eclipse can do the same. But Eclipse is also
able to work with CMakeLists.txt files. Probably a boon as well as a bane, but as other projects are CMake based,
I felt it might be worth a try to try.
So I dived in. I fought for a while to convert my make environment over to CMake. Boost libraries, with v1.69.0
can cause some troubles with CMake find_package abilities. The basic trick is to add the following for builds for v1.69 and possibly for v1.68:
set(CMAKE_CXX_COMPILER_ARCHITECTURE_ID, "x64")
set(Boost_ARCHITECTURE "-x64")
A primary issue undermining my successful transition was that I was using boost::log::trivial. No matter what
I tried, it seems as though a CMake initiated make just wouldn't find the symbols. A message of the kind:
undefined reference to `boost::log::v2s_mt_posix::trivial::logger::get()'
The solution was simple. I had already performed the needed resolution in the old IDE. But forgot to migrate it to the new CMake file.
But as a note for posterity, adding the following to a c++ build line (which also incorporates the link step), will forward options to 'ld', the linker.
-Wl,--trace -Wl,--verbose
These options tell ld to emit additional troubleshooting information. But where to put these flags? I used the following to show the command expansions, which I could then copy and paste and change for
testing (I found the flag in CMakeCache.txt):
build_dir$ cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE ..
The result was that I was indeed successfully resolving the boost_log library inclusion. But why wasn't it accessing the symbols?
The realization occurred after inspecting the library directly, and there is was, the symbol, in all its glory, different from the one for which the linker was originally searching
(variations are discussed on StackOverFlow:
# nm -gC libboost_log-gcc8-mt-x64-1_69.so.1.69.0|grep trivial
0000000000099a80 T boost::log::v2_mt_posix::trivial::logger::get()
Well the solution is to place the following in to the CMakeLists.txt file:
target_compile_definitions(${PROJECT_NAME} PUBLIC BOOST_LOG_DYN_LINK )
This forces the c++ build to use the dynamic boost::log library rather than the static file. The symbol then changes to
`boost::log::v2_mt_posix::trivial::logger::get()'
which can fe found in the dynamic link file. And all is well.
As a side note, when using the CMAKE_VERBOSE_MAKEFILE expansion, with a few tweaks I was able to take a '/usr/bin/c++' invocation and run it instead as
'/usr/bin/ld'. But this doesn't work very well due to many missing libraries, which the linking form of '/usr/bin/c++' automatically provides.
The link command is found in CMakeFiles/${program_name}.dir/link.txt along with other build products.