Unresolved symbols when dynamically loading a shared library

[Blue_Sky_Studios]

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?

[TimP]

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]

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]

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]

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

[Blue_Sky_Studios]

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.