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

8 posts / 0 new

Last post

Wed, 11/18/2015 - 14:25

sumon1

Offline

Last seen: 9 years 2 weeks 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:

[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:

Aarhus University

Thu, 11/19/2015 - 14:11

Fernando Garcia

Offline

Last seen: 4 months 4 weeks ago

Joined: 05/18/2011

Posts: 200

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.

Fri, 11/20/2015 - 00:54

sumon1

Offline

Last seen: 9 years 2 weeks 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.

File Attachments:

This file defines the building process

This properties file defines some other linker and compiler options for different architectures

Fri, 11/20/2015 - 14:55

Fernando Garcia

Offline

Last seen: 4 months 4 weeks ago

Joined: 05/18/2011

Posts: 200

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.

Mon, 11/23/2015 - 01:19

sumon1

Offline

Last seen: 9 years 2 weeks 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

Mon, 11/23/2015 - 09:10

alexc

Offline

Last seen: 2 months 1 week ago

Joined: 04/02/2013

Posts: 196

Hi Sune,

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

Alex

Mon, 11/23/2015 - 13:14

sumon1

Offline

Last seen: 9 years 2 weeks 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

Fri, 11/27/2015 - 01:43

sumon1

Offline

Last seen: 9 years 2 weeks 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

Secondary menu

Navigation

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

RTI Community Portal Terms of Use

Search

Secondary menu

You are here

Navigation

User login

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

RTI Community Portal Terms of Use