Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Blue_Sky_Studios
Beginner
430 Views

Unresolved symbols when dynamically loading a shared library

I am trying to evaluate Intel C++ for Linux on a 64-bit Fedora 12 system. My application loads plug-ins (shared libraries) with dlopen. The dynamic loader should resolve symbols unresolved in the plug-in to symbols in the main executable. This works fine with g++ with no special options in building the executable or plug-ins.

I can load plug-ins built by icpc with a main executable built by g++, but when I try to load either flavor of plug-in from an executable built by icpc, I get unresolved symbols that are, in fact, defined in the main executable.

I am using icpc 11.1.064 and circumventing a bug by pointing to a g++ 4.2 compiler that is not the default (4.4.3). The compile options are these:

-march=core2 -m64 -fp-model precise -ansi -fPIC -fvisibility=default -gcc-name=/opt/gcc424/bin/gcc424 -gxx-name=/opt/gcc424/bin/g++424 -pthread -O2 -fno-strict-aliasing

The -fvisibility=default option was just a last effort to find something that might work.

There are no additional link options, except '-shared -Wl,-soname,foo' for the plug-ins.

What am I missing?

0 Kudos
5 Replies
TimP
Black Belt
430 Views

As you don't identify the unresolved symbols, but apparently they are associated with the recent g++, I guess you have run into a case where icpc doesn't fully support the recent g++ headers or libraries.

I don't believe icpc recognizes -ansi or strict-aliasing options, but it defaults to the equivalent of -fno-strict-aliasing, so it looks like you are OK there. Likewise, I don't think -march=core2 will be recognized as a synonym for -xSSSE3. A recent Core 2 would support -xSSE4.1.

aazue
New Contributor I
430 Views

Hi
My application loads plug-ins (shared libraries) with dlopen.
It is an lib personalized that you having wrote ? or is an standard lib that you can inform ?
void * handle = dlopen ("????????????",????????).
Your options (flag )compiler that you have wrote are perfectly correct,
just test with add (-shared-intel),I don't know is an possibility.
./icpc -fPIC -shared-intel


Kind regards

Blue_Sky_Studios
Beginner
430 Views

The unresolved symbols (actually, it only complains about the first symbol it doesn't find) are in my main executable. It should find them, if they are exposed. dlopen has no trouble finding them, if the main executable is compiled by g++.
Blue_Sky_Studios
Beginner
430 Views

I am loading my own shared libraries with dlopen. I don't think -shared-intel will affect this.
Blue_Sky_Studios
Beginner
430 Views

I found the source of my problem. I thought that I was linking with the same flags as with g++, but I was missing one: -Wl,--export-dynamic.

Thanks for the suggestions.

Reply