Undefined reference to dds::core::<SOME_EXCEPTION> on Raspberry Pi

8 posts / 0 new
Last post
Offline
Last seen: 3 years 9 months ago
Joined: 11/18/2015
Posts: 9
Undefined reference to dds::core::<SOME_EXCEPTION> on Raspberry Pi

Hi there.

I've been searching the internet the whole day for a solution to this problem, but I simply cannot find one.

I'm cross compiling a C++11 NDDS application for the Raspberry Pi using RTI Connext DDS 5.2. I'm using a self compiled toolchain for gcc 5.2 following the instructions in the HOW TO for NDDS on Raspberry Pi.

I am facing a problem with the exceptions in the dds::core. My code compiles just fine, but the linking fails, when I implement error handling with exceptions. The error looks like this:

[INFO] Starting link {4.8 -static-libgcc -L/home/sune/git/cobraid/RemoteEyeUnit/pi/target/nar/dds-1.0.0-arm-Linux-gpp-shared/lib/arm-Linux-gpp/shared -ldds-1.0.0 -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bdynamic -lnddscppz -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bdynamic -lnddscz -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bdynamic -lnddscpp2z -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bdynamic -lnddscorez -Bdynamic -ldl -lnsl -lm -lpthread -lrt -fexceptions -lstdc++}

[INFO] Starting link {4.8 -static-libgcc -L/home/sune/git/cobraid/RemoteEyeUnit/pi/target/nar/dds-1.0.0-arm-Linux-gpp-shared/lib/arm-Linux-gpp/shared -ldds-1.0.0 -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bdynamic -lnddscppz -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bdynamic -lnddscz -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bdynamic -lnddscpp2z -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bdynamic -lnddscorez -Bdynamic -ldl -lnsl -lm -lpthread -lrt -fexceptions -lstdc++}

[ERROR] /home/sune/git/cobraid/RemoteEyeUnit/pi/target/nar/obj/arm-Linux-gpp/pi.o: In function `cobraid::Subscriber::createDataReader()':

[ERROR] pi.cpp:(.text._ZN7cobraid10SubscriberI7ControlE16createDataReaderEv[_ZN7cobraid10SubscriberI7ControlE16createDataReaderEv]+0x1c8): undefined reference to `dds::core::InvalidArgumentError::InvalidArgumentError(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)'

 To me it seems like the linking is not able to link the library in which dds::core::InvalidArgumentError is implemented. When I run this code without the -static-libgcc it compiles and links just fine, but I get a segmentation fault on the Raspberry Pi, because of the hard floating points.

I've tried to run the code on the host machine (Ubuntu 14.04LTS 64-bit) without static linking stdc++, and it runs without any problems.

I'm using a Maven plugin named Maven NAR for compiling my C++11 project, which gives the information and error syntax above.

Any ideers why the dds::core exceptions doesn't seem to work on the Raspberry Pi?

Best regards

Sune
Software Engineer student at Aarhus University Denmark

 

 

Organization:
Fernando Garcia's picture
Offline
Last seen: 2 days 8 hours ago
Joined: 05/18/2011
Posts: 196

Hi Sune,

I have taken a look at the makefile that rtiddsgen generates for building a C++11 example that is going to run on a Raspberry Pi (armv6vfphLinux3.xgcc4.7.2). And this is what I have found:

COMPILER = arm-linux-gnueabihf-g++
COMPILER_FLAGS = -std=c++0x
LINKER = arm-linux-gnueabihf-g++
LINKER_FLAGS =
SYSLIBS = -ldl -lnsl -lm -lpthread -lrt
DEFINES = -fpic -DRTI_UNIX -DRTI_LINUX -march=armv6 -mfpu=vfp -mfloat-abi=hard -mlong-calls

It looks like require passing the -std=c++0x compiler flag, but I do not know whether you are passing it already. If you are not, please add it to your build.

If this does not work, can you share with us the makefile you are using or a more verbose output including both the command you use to compile and link? Also, can you share some instructions on how to install the toolchain you are using?   

Thanks,
Fernando. 

Offline
Last seen: 3 years 9 months ago
Joined: 11/18/2015
Posts: 9

Hi Fernando.

Thank you for the answer. 
Since I'm using Maven instread of make to build my project, I do not have a makefile, but I can provide The compile and linker options that I'm using. 
When I sat up the project I did the same thing, namely set the flags that where set in the autogenerated makefile for the idl's.

I've attached my pom.xml file (which is defining the build process). Some of the NDDS libraries are linked in the linker section in the the nar plugin section in the pi profile. Other settings are loaded from the other attachment aol.properties (renamed to aol.txt because the forum don't like tike the .properties extension). I hope it's not to confusing.

The toolchain was built using the crosstool-ng. We had to built the latest development built to support gcc5.2. This is done using the following commands:

git clone git://crosstool-ng.org/crosstool-ng
cd crosstool-ng
./bootstrap
./configure --enable-local
make
./ct-ng menuconfig

There might be some dependencies which has to be installed as well. I had to install the following dependencies before running ./configure --enable-local:

sudo apt-get install autoconf
autoconf
sudo apt-get install gperf bison flex texinfo gawk libtool libncurses5-dev

  

The following properties are sat in the menuconfig

  • Paths and misc options
    • Try features marked as EXPERIMENTAL
    • In prefix directory indicate the directory where you want your toolchain. In this case: ${HOME}/toolchains/raspbian-toolchain-gcc-5.1-linux32
  • Target options
    • Target architecture: arm
    • Endianness: Little endian
    • Bitness: 32-bit
    • Floating point: hardware (FPU)
  • Toolchain options
    • Build static toolchain (Experimental)
    • Toolchain bug url: http://community.rti.com
    • Tuple's vendor string: raspbian
    • Tuple's alias: arm-linux-gnueabihf
  • Operating system
    • Target OS: Linux
    • You can also select the kernel version you run in your target. In this case, use 4.1.6-v7+
  • C compiler
    • C compiler: gcc
    • gcc version: 5.2.0
    • In additional supported languages add C++

thanks again.

Sune

ps. When I'm not using the built in dds exceptions, then it builts, links and runs with no problems.

Fernando Garcia's picture
Offline
Last seen: 2 days 8 hours ago
Joined: 05/18/2011
Posts: 196

Hi Sune,

We just noticed that the order in which the libraries are linked is swapped and that may be causing your problem. You should link against the C++ library before linking against the C, and Core libraries (i.e., the order should be -lnddscpp2z -lnddscz -lnddscorez). Even though we have not tried to build your specific toolchain with our toolchain based on 4.7.2 this defintiely causes problem. Note also that the order in which the libraries are linked is right in other parts of your pom.xml file.

Here is how you can modify your pom.xml (I think the order in which the libraries are linked is right in other parts of your pom.xml file):

 <profile>
    <id>pi</id>
    ....
    <plugins>
        <plugin>
          <groupId>com.github.maven-nar</groupId>
          <artifactId>nar-maven-plugin</artifactId>
          <version>3.2.3</version>
          <extensions>true</extensions>
          <configuration>
             <architecture>arm</architecture>
             <skipTests>true</skipTests>
             <linker>
             <libs>
                 <lib>
                     <name>nddscppz2</name>
                     <directory>${env.NDDSHOME}/lib/armv6vfphLinux3.xgcc4.7.2</directory>
                     <type>shared</type>
                 </lib>
                 <lib>
                     <name>nddscppz</name>
                     <directory>${env.NDDSHOME}/lib/armv6vfphLinux3.xgcc4.7.2</directory>
                     <type>shared</type>
                 </lib>
                 <lib>
                     <name>nddscz</name>
                     <directory>${env.NDDSHOME}/lib/armv6vfphLinux3.xgcc4.7.2</directory>
                     <type>shared</type>
                 </lib>
                 <lib>
                     <name>nddscorez</name>
                     <directory>${env.NDDSHOME}/lib/armv6vfphLinux3.xgcc4.7.2</directory>
                     <type>shared</type>
                 </lib>
              </libs>
              <clearDefaultOptions>true</clearDefaultOptions>
...

We also noted that these libraries are marked as shared, but they are static libraries. I think that is what adds -BDynamic to the linker.

Please let me know if this fixes your issue,
Fernando.

Offline
Last seen: 3 years 9 months ago
Joined: 11/18/2015
Posts: 9

Hi Fernando.

I've changed the order in which the libraries are loaded, and changed the linking to static, but it doesn't seem to make a difference.

Starting link {4.8 -static-libgcc -L/home/sune/git/cobraid/RemoteEyeUnit/pi/target/nar/dds-1.0.0-arm-Linux-gpp-shared/lib/arm-Linux-gpp/shared -ldds-1.0.0 -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bstatic -lnddscpp2z -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bstatic -lnddscppz -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bstatic -lnddscz -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bstatic -lnddscorez -Bdynamic -ldl -lnsl -lm -lpthread -lrt -fexceptions -lstdc++}

[INFO] Starting link {4.8 -static-libgcc -L/home/sune/git/cobraid/RemoteEyeUnit/pi/target/nar/dds-1.0.0-arm-Linux-gpp-shared/lib/arm-Linux-gpp/shared -ldds-1.0.0 -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bstatic -lnddscpp2z -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bstatic -lnddscppz -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bstatic -lnddscz -L/home/sune/rti_connext_dds-5.2.0/lib/armv6vfphLinux3.xgcc4.7.2 -Bstatic -lnddscorez -Bdynamic -ldl -lnsl -lm -lpthread -lrt -fexceptions -lstdc++}

[ERROR] /home/sune/git/cobraid/RemoteEyeUnit/pi/target/nar/obj/arm-Linux-gpp/pi.o: In function `main':
[ERROR] pi.cpp:(.text+0x324): undefined reference to `dds::core::NullReferenceError::NullReferenceError(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)' [ERROR] collect2: error: ld returned 1 exit status

I've inserted another exception just for test purposes, but that shouldn't make a difference. I still compiles fine, but the linking fails. The library dds-1.0.0 is a maven dependency containing the classes that I generated from my IDL, in case you wonder what the dynamic linking is about.

If I remove the library nddscpp2z from the linker, then there is an undefined reference to the destructor as well as an undefined reference to the constructor, so it seems like parts of the implementation is found during the linking process, but the constructor seems to be the one causing the problem.

Here is how I call the constructor:


const std::string msg= "Test";
throw dds::core::NullReferenceError(msg);

Sune

Offline
Last seen: 1 week 2 days ago
Joined: 04/02/2013
Posts: 110

Hi Sune,

Do you get the same problem if you compile a C++03 example instead of C++11?

Alex

Offline
Last seen: 3 years 9 months ago
Joined: 11/18/2015
Posts: 9

Hi Alex. 

Everything works as it should as long as I don't use the rti core exceptions. I have no problems in using my own custom exceptions. C++03 is not an option since I'm using C++11 throughout the entire project, and the dds core exceptions uses a lot of c++11 themselves including the move operations as far as I know.

Sune

 

Offline
Last seen: 3 years 9 months ago
Joined: 11/18/2015
Posts: 9

Hi Alex and Fernando.

Thanks for your sugestions. I never got it to work with RTI Exceptions, but for now that's allright. I'm using some custom exceptions instead. It is still a bit weird why it wasn't possible though

//Sune