Compile error on simCore::checkVersionThrow()

[faculaganymede]

SIMDIS SDK Gurus,

I'm trying to compile the example code /SIMDIS_SDK/share/ExternalSdkProject/VisExample/VisExample.cpp on Qt Creator and keep getting the below compilation errors. If I change the first line simCore::checkVersionThrow() to simCore::checkVersion(), then the code compiles and runs OK.

I'm using SIMDIS SDK 1.17 on RHEL 8.9 with Qt 5.9.8. I can successfully compile the SIMDIS SDK from source code but my own compiled version of the SIMDIS SDK libraries gives the same compilation errors.

main.cpp

#include "simCore/Common/Version.h"
#include "simVis/Viewer.h"
#include "simUtil/ExampleResources.h"

int main(int argc, char* argv[])
{
  simCore::checkVersionThrow();
  osg::ArgumentParser arguments(&argc, argv);
  simExamples::configureSearchPaths();

  // Set up OSG features if supported
  osg::DisplaySettings::instance()->setNumMultiSamples(4);

  // initialize a SIMDIS viewer and load a planet.
  osg::ref_ptr<simVis::Viewer> viewer = new simVis::Viewer(arguments);
  viewer->setMap(simExamples::createDefaultExampleMap());

  // start in a windowed mode
  viewer->getMainView()->setUpViewInWindow(100, 100, 1024, 768);
  // set an initial viewpoint
  viewer->getMainView()->lookAt(38.89511, -77.03637, 0, 0, -89, 5e6);

  // add debug handlers like stats and fullscreen mode (s and f hotkeys)
  viewer->installDebugHandlers();

  return viewer->run();
}

Compilation errors:

g++ -Wl,-O1 -Wl,-rpath,/home/facula/Qt5.9.8/5.9.8/gcc_64/lib -o simdis main.o mainwindow.o moc_mainwindow.o   -L/home/facula/SIMDIS/SIMDIS_SDK/lib -lsimCore -lsimNotify -lsimUtil -lsimVis -lsimQt -lsimData -lgdal -lgeos -lgeos_c -losg -losgUtil -losgViewer -losgDB -losgGA -losgText -lOpenThreads -losgShadow -losgSim -losgTerrain -losgQt5 -losgAnimation -losgWidget -losgEarth -losgEarthTriton -losgEarthSilverLining -L/home/facula/Qt5.9.8/5.9.8/gcc_64/lib -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread 
main.o: In function `simCore::Exception::~Exception()':
main.cpp:(.text._ZN7simCore9ExceptionD2Ev[_ZN7simCore9ExceptionD5Ev]+0x7a): undefined reference to `simNotify::NotifyHandler::operator<<(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
main.o: In function `simCore::LibraryVersionError::~LibraryVersionError()':
main.cpp:(.text._ZN7simCore19LibraryVersionErrorD2Ev[_ZN7simCore19LibraryVersionErrorD5Ev]+0x7a): undefined reference to `simNotify::NotifyHandler::operator<<(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
main.o: In function `simCore::Exception::~Exception()':
main.cpp:(.text._ZN7simCore9ExceptionD0Ev[_ZN7simCore9ExceptionD5Ev]+0x82): undefined reference to `simNotify::NotifyHandler::operator<<(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
main.o: In function `simCore::LibraryVersionError::~LibraryVersionError()':
main.cpp:(.text._ZN7simCore19LibraryVersionErrorD0Ev[_ZN7simCore19LibraryVersionErrorD5Ev]+0x82): undefined reference to `simNotify::NotifyHandler::operator<<(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status
make: *** [Makefile:249: simdis] Error 1
06:07:14: The process "/usr/bin/make" exited with code 2.
Error while building/deploying project simdis (kit: Desktop Qt 5.9.8 GCC 64bit)
When executing step "Make"

[emminizer]

Hello, this is a good question. It had me scratching my head for a minute too before I realized the issue.

The issue is a g++ / linker issue. As often with these, the first line gives the biggest hint to the problem:

main.cpp:(.text._ZN7simCore9ExceptionD2Ev[_ZN7simCore9ExceptionD5Ev]+0x7a): undefined reference to `simNotify::NotifyHandler::operator<<(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'

Your application is being compiled with the wrong ABI. It looks like you compiled SIMDIS SDK with the CXX-03 ABI (the default, and what we redistribute). Around gcc-5, there was a new C++ ABI introduced (cxx11 ABI) that broke binary compatibility. RHEL7 (just found out this past week) doesn't even support the new cxx11 ABI; on the EL side it's not available until EL8. So kudos for mentioning EL8.9.

Part of this is due to using a build configuration that we don't support (Qt Designer). We do support CMake, and provide examples of how to build against the SDK installed project with CMake. Take a look at your installation folder's share/ExternalSdkProject -- not the source code version, which is used as part of the configure stage for what gets put in installation's share/ folder. I recommend using that configuration because it gets tested. There are very possibly other flags or configuration options that get missed if you don't use CMake.

The issue is solved in CMake with the CMakeModules/EnableNewCxxFeatures.cmake. Specifically, linking to any of those SDK objects should use the -D_GLIBCXX_USE_CXX11_ABI=0 definition added to your compile line.

We do not currently support the cxx11 ABI with our distributions. We're looking into it, but it requires rebuilds of all libraries and is not a trivial task. At this time we don't provide 3rd party packs with cxx11 ABI, and do not test that ABI at all.

Hope this helps.

• Dan

[AndrewBrennanCiv]

Dan, when you mention EL7 not supporting abi11, do you mean abi17? I can say from experience that the default C++ versions for RHEL6 is C++03, RHEL7 is C++11, and RHEL8 is C++17. Just wanted to clarify for everyone because the errors mentioned here look oddly familiar.

Andrew Brennan

On Mar 10, 2023, at 7:34 AM, Daniel Emminizer @.***> wrote:



Hello, this is a good question. It had me scratching my head for a minute too before I realized the issue.

The issue is a g++ / linker issue. As often with these, the first line gives the biggest hint to the problem:

main.cpp:(.text._ZN7simCore9ExceptionD2Ev[_ZN7simCore9ExceptionD5Ev]+0x7a): undefined reference to `simNotify::NotifyHandler::operator<<(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)'

Your application is being compiled with the wrong ABI. It looks like you compiled SIMDIS SDK with the CXX-03 ABI (the default, and what we redistribute). Around gcc-5, there was a new C++ ABI introduced (cxx11 ABI) that broke binary compatibility. RHEL7 (just found out this past week) doesn't even support the new cxx11 ABI; on the EL side it's not available until EL8. So kudos for mentioning EL8.9.

Part of this is due to using a build configuration that we don't support (Qt Designer). We do support CMake, and provide examples of how to build against the SDK installed project with CMake. Take a look at your installation folder's share/ExternalSdkProject -- not the source code version, which is used as part of the configure stage for what gets put in installation's share/ folder. I recommend using that configuration because it gets tested. There are very possibly other flags or configuration options that get missed if you don't use CMake.

The issue is solved in CMake with the CMakeModules/EnableNewCxxFeatures.cmake. Specifically, linking to any of those SDK objects should use the -D_GLIBCXX_USE_CXX11_ABI=0 definition added to your compile line.

We do not currently support the cxx11 ABI with our distributions. We're looking into it, but it requires rebuilds of all libraries and is not a trivial task. At this time we don't provide 3rd party packs with cxx11 ABI, and do not test that ABI at all.

Hope this helps.

• Dan

— Reply to this email directly, view it on GitHubhttps://github.com/USNavalResearchLaboratory/simdissdk/issues/96#issuecomment-1463890367, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGHQUOKNCBXRSBU7EBPAPATW3M3WDANCNFSM6AAAAAAVWQUI6Y. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[AndrewBrennanCiv]

Dan, when you mention EL7 not supporting abi11, do you mean abi17? I can say from experience that the default C++ versions for RHEL6 is C++03, RHEL7 is C++11, and RHEL8 is C++17. Just wanted to clarify for everyone because the errors mentioned here look oddly familiar.

[faculaganymede]

Hi Dan,

Thank you so much for your detailed explanation. You don't know how much I appreciate your reply. I've spent so much time trying to figure this out, thinking it's an API library version compatibility issue because I've previously installed other versions of the 3rd party libraries on my system.

You are absolutely correct that the problem was caused by ABI compatibility. I added QMAKE_CXXFLAGS += -D_GLIBCXX_USE_CXX11_ABI=0 to Qt Creator and that resolved the problem. Thank you again!!

[emminizer]

@AndrewBrennanCiv No, I'm not referring to the C++ version, I'm referring to the default ABI. They are distinct. You can compile C++17 or C++20 with the CXX11 ABI, or with the older (CXX03?) ABI. See https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html for some details. It seems there was a conscientious decision to avoid tying together the C++ version with the ABI, which is great.

Furthermore, although RHEL7's default compiler (4.8.5) can build most (all?) C++-11 code, but is not fully C++11 compliant; it will crash on some code. We had enough problems with it that we couldn't use it and had to upgrade past. It isn't until g++ 5.x that C++11 is fully supported, and it's not until 5.x and EL8 that the CXX11 ABI is fully supported.

@faculaganymede Glad to help. I'm hoping we can start to package the CXX11 ABI binaries in the next year or two, it is on our to-do list.