undefined symbols uw_parse_lsda_info and ReadULEB

[apl1]

I'm trying to link icc compiled code with g++ compiled code. If I use icc to do the linking, I get segfaults in object destructors at program exit. If I use g++ to do the linking, I end up with undefined symbols.

I've done a

nm -AC *.a | grep ReadULEB

to try and find what library defines these things, but
it doesn't seem to be defined anywhere.... Am I forgetting something really silly?

/home/oldapl/build-gcc-3.2.1/dist/icc-dist/lib/libcxa.so.3: undefined reference to `_uw_parse_lsda_info'
/home/oldapl/build-gcc-3.2.1/dist/icc-dist/lib/libcxa.so.3: undefined reference to `_dw2_size_of_encoded_value'
/home/oldapl/build-gcc-3.2.1/dist/icc-dist/lib/libcxa.so.3: undefined reference to `_dw2_read_encoded_value'
/home/oldapl/build-gcc-3.2.1/dist/icc-dist/lib/libcxa.so.3: undefined reference to `_ReadULEB'
/home/oldapl/build-gcc-3.2.1/dist/icc-dist/lib/libcxa.so.3: undefined reference to `_ReadSLEB'

[Ganesh_R_Intel]

apl,
Thanks for using the forum.

You didnt tell me if the original code was in C or C++.
If it is C, you should be able to mix and match with gcc/Intel built binaries.
You cannot mix and match C++ code with the 7.0 version of the Intel compiler and gcc. This is because
(i) currently we are not supporting libgcc. We are implementing libcxa/libunwind as supplied with the ditribution.
Please note that additionally, gcc is Application Binary Interface (ABI) standard compatible only as of gcc 3.2. Earlier versions are not.

With a future version of the Intel compiler, we hope to be able to support gcc standard C++ library implementations allowing for a binary mix and match with gcc 3.2 or greater since Intel compilers are also ABI standard compliant.

Does that make sense?

Thanks,
Ganesh

[apl1]

>
> You didnt tell me if the original code was in C or
> C++.

C++

>....
> You cannot mix and match C++ code with the 7.0
> version of the Intel compiler and gcc. This is
> because
> (i) currently we are not supporting libgcc. We are
> implementing libcxa/libunwind as supplied with the
> ditribution.

The g++ code was all compiled with -fno-exceptions.

> Please note that additionally, gcc is Application
> Binary Interface (ABI) standard compatible only as of
> gcc 3.2. Earlier versions are not.

Right. I'm very aware of that. This is using g++ 3.2.1,
and running icc with flags to cause it to search the gcc libraries and headers

I pass the following switches to my icc compiles -
-X
-Idirafter -I/tools/linux/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/include/
-Idirafter -I/tools/linux/gcc-3.2.1/include/c++/3.2.1/
-Idirafter -I/tools/linux/gcc-3.2.1/include/c++/3.2.1/i686-pc-linux-gnu/
-Idirafter -I/tools/linux/gcc-3.2.1/include/c++/3.2.1/backward/
-Idirafter -I/tools/linux/gcc-3.2.1/include/
-Idirafter -I/usr/local/include/
-Idirafter -I/usr/include/
-D__builtin_alloca=_alloca
-D__GNUC__=3
-D__GNUC_MINOR__=2
-D__GNUC_PATCHLEVEL__=0
-D__GXX_ABI_VERSION=102
-D__ELF__
-Dunix
-D__gnu_linux__
-Dlinux
-D__ELF__
-D__unix__
-D__gnu_linux__
-D__linux__
-D__unix
-D__linux
-Asystem=posix
-D__NO_INLINE__
-D__STDC_HOSTED__=1,
-D_GNU_SOURCE
-Acpu=i386
-Amachine=i386
-Di386
-D__i386
-D__i386__
-D__tune_i686__
-D__tune_pentiumpro__
-D__GNUG__=3
-D__DEPRECATED
-D__EXCEPTIONS


>
> With a future version of the Intel compiler, we hope
> to be able to support gcc standard C++ library
> implementations allowing for a binary mix and match
> with gcc 3.2 or greater since Intel compilers are
> also ABI standard compliant.
>
> Does that make sense?

Yes. Although I "need" to be able to do this *now* if at all possible.

[Ganesh_R_Intel]

>The g++ code was all compiled with -fno-exceptions.
For you to make any meaningful headway you would need to be using libgcc instead of libcxa and that is not just the unwind library.