Skip to Main Content

DevOps, CI/CD and Automation

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Sun Studio linking gcc libs: exceptions do not work

User_7ZJ07Dec 16 2014 — edited Dec 16 2014

I need to build an application with Sun Studio. This application uses a shared library which can only be build with Gnu C++. The shared lib has a C Interface, so that the code is callable by the Sun Compiler (this is to avoid name mangling issues, see also this question).

Everything besides exception handling works fine. When an exception is thrown in the shared library, the program segfaults. This happens only when the main program is compiled using the Sun Studio Compiler. Compiling the minimal example below with the Gnu C++ compiler, the program works fine and the shared lib detects the exception.

Plan A: link dynamically Here is an illustration of the setup:

GCC                         SOLARIS STUDIO
                  shared
clayer
.so         <-----    application
(no exceptions)             (uses exceptions sol studio)
  
|
  
| use flag -static -static-libstdc++ -static-lib-gcc
   v
gcc_only_lib
.so
libstdc
++.so
(uses gcc exceptions
)

Result: segmentation violation once an exception is thrown


---------------------------------------------------------------

Here is a minimal example to reproduce the problem:

exampleMain.cpp:

#include <clayer.h> #include <stdio.h> 

int main(int argc, char **argv) {

  if (!clayerCall()) printf("got exception\n");

  else printf("OK\n");

}

shared lib header:

extern "C" {  bool clayerCall();  } // end extern "C" 

shared lib source:

#include "clayer.h" 

#include <exception>

#include <stdexcept>

#include <stdio.h> 

extern "C" { 

     bool clayerCall() {

     try {

          throw std::runtime_error("hhh");

          return true;

     } catch (std::exception &ex) { return false; }

} 

} // end extern c


The cmake files look like this:

for the executable

project(exampleMain)

cmake_minimum_required(VERSION 2.8)

set(CMAKE_BUILD_TYPE Debug)

add_definitions(-m64 -fPIC) 

include_directories(../oracle_example) 

link_directories ( ../oracle_example) 

add_executable(example exampleMain.cpp)

target_link_libraries( example stdc++ clayer )

for the library

project(clayer)

cmake_minimum_required(VERSION 2.8)

cmake_policy(VERSION 2.8)

set(CMAKE_BUILD_TYPE Debug) 

add_library( clayer SHARED clayer.cpp )

Comments

Steve.Clamage-Oracle

This question really belongs in the Solaris Studio C/C++/Fortran Compilers forum:

https://community.oracle.com/community/server_%26_storage_systems/systems-development-and-management-tools/application_d…

You don't show how you are building your program, and you don't say which version of Studio you are using, or the platform you are using. All of this data is important to understand your issue.

You are mixing binary code created by the Studio C++ compiler with code built with g++. That will work only under these conditions:

- You must use the -compat=g option with Studio C++ on every CC command, compiling and linking. (If  you are using Studio 12.4, you can use -std=c++03 or -std=c++11 instead.)

- The g++ compiler must be compatible with the version expected by the Studio C++ compiler, which depends on the Studio version.

- Only shared libraries (.so files) created by g++ can be linked, not .o or .a files.

- The compiler (CC or g++)  that builds the main program must be used to link the final program.

If you meet all these conditions and the code still fails, please show

- the Studio version (run the command "CC -V"),

- the g++ version (run "g++ -v"),

- the platform (operating system and version, and whether it is Sparc or x86), and

- show how you build the program.

1 - 1
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Jan 13 2015
Added on Dec 16 2014
1 comment
1,003 views