Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor III
12 Views

Problem building customso sample on ubuntu 9.04

Hi,
using ipp 6.1.2.051 and corresponding samples, i can't achieve to link properly with libiomp5.a
First of all I had to modify the makefile which contained a little error for building the library path. Once done, here is what I get :
ld -shared -o bin/linux32_gcc4/libusr_t.so library.script bin/linux32_gcc4/init.o -L/lib/ia32 -L/opt/intel/ipp/6.1.2.051/ia32/lib -L./bin/linux32_gcc4 -lippiemerged -lippimerged_t -lippsemerged -lippsmerged_t -lippcore_t /opt/intel/ipp/6.1.2.051/ia32/lib/libsvml.a /opt/intel/ipp/6.1.2.051/ia32/lib/libimf.a /opt/intel/ipp/6.1.2.051/ia32/lib/libirc.a /opt/intel/ipp/6.1.2.051/ia32/lib/libirc_s.a /opt/intel/ipp/6.1.2.051/ia32/lib/libiomp5.a -L/opt/intel/ipp/6.1.2.051/ia32/sharedlib -liomp5 -lpthread -lm -lc
ld: /usr/lib/libpthread_nonshared.a(pthread_atfork.oS): relocation R_386_GOTOFF against undefined hidden symbol `__dso_handle' can not be used when making a shared object
ld: final link failed: Bad value
make: *** [bin/linux32_gcc4/libusr_t.so] Error 1

[edit]I couldn't find a workaround other that linking to libiomp5.so but then when linking the test application, pthread_atfork could not be resolved in libiomp5.so......

If anyone has any idea ?

Matthieu
0 Kudos
5 Replies
Highlighted
New Contributor III
12 Views

Found a workaround,
linking with gcc works well when changing _init with void __attribute__ ((constructor)) my_init(void) in init.c

Now I have another problem with the same sample under ubuntu 9.04 em64t...

libiomp5.a seems to have been compiled with -fnopic... thus non linking in a shared library.

The sample tries to link against both libiomp5.a and libiomp5.so (in ia32 and em64t) which one should be used for a custom so (the question is also valid on windows...)

Matthieu
0 Kudos
Highlighted
Employee
12 Views

Hi Matthieu!

About first issue "/usr/lib/libpthread_nonshared.a(pthread_atfork.oS): relocation R_386_GOTOFF":
I met the same problem in the RedHat EL5 and I found this pboblem in the Ubuntu bugs tracker: https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/358665
About RedHat - there was wrong libpthread.so library and it solved by upgraged pthread libraries.
You could solve the problem by changing _init with void __attribute__ ((constructor)) - could you say the version of ld which you use?. I'll investigate this.

About second issue: "libiomp5.a isn't pic in linux em64t" - yes, I know about it, unfortunatelly it is the problem of Intel compiler and I can't help you in it. You should use shared version "libiomp5.so" for solving this problem.

Pavel

0 Kudos
Highlighted
New Contributor III
12 Views

Quoting - Pavel Berdnikov

Hi Matthieu!

About first issue "/usr/lib/libpthread_nonshared.a(pthread_atfork.oS): relocation R_386_GOTOFF":
I met the same problem in the RedHat EL5 and I found this pboblem in the Ubuntu bugs tracker: https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/358665
About RedHat - there was wrong libpthread.so library and it solved by upgraged pthread libraries.
You could solve the problem by changing _init with void __attribute__ ((constructor)) - could you say the version of ld which you use?. I'll investigate this.

About second issue: "libiomp5.a isn't pic in linux em64t" - yes, I know about it, unfortunatelly it is the problem of Intel compiler and I can't help you in it. You should use shared version "libiomp5.so" for solving this problem.

Pavel


Thanks for your answer,

I also found the entry in the Ubuntu bug tracker. Being a newbie in this linux world, I really don't know how to upgrade my system more than it already is (Synaptic Packet Manager doesn't find any new updates - already updated all that could be updated).
I didn't change only the init routine (from legacy form to gcc new form) of the library, I also changed the way the linker is called : I now use gcc to link instead of ld. It wouldn't work with ld alone. The version of ld is 2.19.1 and the version of gcc is 4.3.3.

I guess I'll wait for someone at Intel reading this thread to explain why there's no pic version of libiomp5.a in linux em64t.

Regards,
Matthieu
0 Kudos
Highlighted
Employee
12 Views

Hi Matthieu!

I work for Intel in the Intel Performance Primitive group. As I said before: the nonpic code in the libiomp5.a - was the bug of Intel compiler, it was fixed in the Intel compiler 11.1 but for IPP 6.1 we use more older version Intel compiler and use libiomp5.a library withthis bug as result.

Pavel.

0 Kudos
Highlighted
New Contributor III
12 Views

Quoting - Pavel Berdnikov

Hi Matthieu!

I work for Intel in the Intel Performance Primitive group. As I said before: the nonpic code in the libiomp5.a - was the bug of Intel compiler, it was fixed in the Intel compiler 11.1 but for IPP 6.1 we use more older version Intel compiler and use libiomp5.a library withthis bug as result.

Pavel.


Thanks for the clarification. So if I use the version provided with ICL, should it work or can I expect some problems because of different versions ?

Regards,
Matthieu
0 Kudos