RTI 5.1 crashing VS compiler when exporting symbols

9 posts / 0 new
Last post
Offline
Last seen: 10 years 8 months ago
Joined: 03/12/2014
Posts: 1
RTI 5.1 crashing VS compiler when exporting symbols

Has anyone else ran across a problem with RTI 5.1 crashing the Visual Studio (2008, 2010, and 2012) compiler when exporting symbols using the CORBA compatibility kit and the NDDS_USER_DLL_EXPORT macro?

I can consistently reproduce the error with the provided Message example (%NDDSHOME%\example\CPP\corba) by adding a "stub" mpc file to build MessageC, Message, MessagePlugin, and MessageSupport into a library.  Since its a shared library, the symbols must be exported via the NDDS_USER_DLL_EXPORT macro to be able to access the generated classes.  The code that crashes the compiler is in the MessageSupport.h file:

#ifdef __cplusplus
  /* If we're building on Windows, explicitly import the superclasses of
   * the types declared below.
   */        
  class __declspec(dllimport) ::DDSTypeSupport;
  class __declspec(dllimport) ::DDSDataWriter;
  class __declspec(dllimport) ::DDSDataReader;
#endif

Removing the scope identifiers (::) from the forward declarations resolves the problem.  However, I'd like rtiddsgen to do it since manually modifying generated files isn't reasonable in my environment.

When using RTI 5.0 the MessageSupport.h file is the same as for 5.1 but does not crash the compiler.

Has anyone else seen this problem or have input?

jwillemsen's picture
Offline
Last seen: 3 years 5 months ago
Joined: 09/24/2013
Posts: 55

We are using this feature heavily as part of the CIAO DDS4CCM implementation but we only use RTI DDS 5.0.0 at this moment.  Will see if I can tweak one of our builds to try 5.1.0 on Windows

jwillemsen's picture
Offline
Last seen: 3 years 5 months ago
Joined: 09/24/2013
Posts: 55

I can confirm we see the same, RTI 5.1.0 with Visual Studio causes an internal compiler error when using the CCK and compiling the type support into a shared library. I will open a support ticket to RTI for this.

Ashish's picture
Offline
Last seen: 8 years 4 months ago
Joined: 07/16/2013
Posts: 8

Hi,

What about building STATIC library from TypeSupport code instead of SharedObject? 

I just tested using CCK for C++ under Linux. So If we build a STATIC libs(*.a) insted of SHARED OBJECT (*.so). There are no compiler errors related to Symbol resolution. No need to remove the scope identifiers (::) in MessageSupport.h. (Of Course while using STATIC libs there are no dependencies resolved at link time). 

run "ar -cvq libMessageStatic.a MessageC.o Message.o MessagePlugin.o  MessageS.o MessageSupport.o"

Thanks,

jwillemsen's picture
Offline
Last seen: 3 years 5 months ago
Joined: 09/24/2013
Posts: 55

Windows or Linux, two environments you really can't compare. For us it is not possible to build static, we need shared libraries because our complete architecture is based on it.

Ashish's picture
Offline
Last seen: 8 years 4 months ago
Joined: 07/16/2013
Posts: 8

Hi Johnny,

I missed to state, under Linux/CCK while using *.so (build from TypeSupport source files) there are similar compiler errors related to symbol resolution as stated by Dennis in his initial post.

I got it around using static lib, and removing the scope identifiers (::) from the forward declarations in MessageSupport.h does not resolves the problem under Linux/CCK. 

I haven’t tried it on Windows/VS environment yet. But it looks like, there are similarities in compiler symbol resolution errors on Windows/CCK/VS and Linux/CCK/gcc for C++.

Thanks,

jwillemsen's picture
Offline
Last seen: 3 years 5 months ago
Joined: 09/24/2013
Posts: 55

In the past we never have been able to get the TypeSupport files compiled into a shared library on Linux in combination with hidden symbol visibility, that is why we don't use the exports really on Linux (there should be a ticket for supporting this already). On Windows it did work without problems, but now it doesn't anymore.

Ashish's picture
Offline
Last seen: 8 years 4 months ago
Joined: 07/16/2013
Posts: 8

Hi Johnny,

Many thanks for the pointer "hidden symbol visibility" under Linux. We have updated your ticket.

 

 

jwillemsen's picture
Offline
Last seen: 3 years 5 months ago
Joined: 09/24/2013
Posts: 55

The Windows problem has been confirmed by RTI Support, the fix is as mentioned, remove the double semi-colon.