2

I am building a shared object on Ubuntu 16.04 which uses libgomp. My goal is to make this final object as portable as possible, by static linking anything not normally in a base distribution (using docker ubuntu or alpine images as a reference baseline). I've been able to do this with my other dependencies pretty easily, but I'm hung up on libgomp.

I can link just fine with the -fopenmp option, and get a dynamic link:

# ldd *.so
linux-vdso.so.1 =>  (0x00007fff01df4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9ba59db000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f9ba57b9000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9ba55a3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9ba5386000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9ba4fbc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9ba6516000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9ba4db8000)

But if I naively add -static before -fopenmp I get:

relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC

Fair enough; with my other dependencies I've just built from source to enable PIC and any other options I needed. When I try to do the same with libgomp, though, I'm not having any luck. I checked out gcc 5.5 from http://gcc.gnu.org/svn/gcc, and tried building from the gcc/libgomp folder. There is a configure script already generated, but running it returns:

./config.status: line 1486: ./../../config-ml.in: No such file or directory

OK, apparently this has something to do with multilibrary support, which I don't believe I need. Running ./configure --help shows that there is an --enable-multilib option with no obvious default, but setting --enable-multilib=no or --disable-multilib still returns the same error. I've also tried running autoreconf -fiv to regenerate the configure script, but I get this error:

configure.ac:5: error: Please use exactly Autoconf 2.64 instead of 2.69.

If I explicitly install and use autoreconf2.64, I get this one:

configure.ac:65: error: Autoconf version 2.65 or higher is required

What am I missing?

superstator
  • 3,005
  • 1
  • 33
  • 43
  • 1
    Statically linking the OpenMP runtime (or any other threading runtime) is generally a bad idea. It can lead to multiple copies of the runtime in the process, each of which will maintain its own pool of threads, leading to over-subscription and poor performance, as well as correctness problems if you're sharing data between code that is running in parallel using the different runtimes (since each has its own, internal, set of locks). – Jim Cownie Jan 22 '18 at 16:43
  • Thank you for that explanation. A little more background; we have a C++ library which is consumed exclusively by a .NET Standard library for use under .NET Core. I'm honestly not sure where the libgomp dependency gets inserted. .NET Core distributions do not include any OpenMP support themselves, so without statically linking libgomp we risk throwing a very generic DllImport exception on vanilla systems. My thinking was that since it's not being distributed with the Core runtime, it would be safe to shoehorn in this way, but perhaps not? – superstator Jan 22 '18 at 17:32
  • The danger arises if any of the other code that the user is including in her program is also using OpenMP. You are hiding the fact that you are, and some other library may be doing the same... – Jim Cownie Jan 24 '18 at 11:13

1 Answers1

4

What I was missing was the fact that libgomp is not buildable separate from the rest of gcc. It was just a matter of going up a level and running the whole build with -fPIC enabled:

export CFLAGS="-O3 -fPIC"
export CXXFLAGS="-O3 -fPIC"
./configure --disable-multilib --enable-languages=c,c++
make
make install

That gave me a copy of libgomp.a in /usr/local/lib64 ready for linking in to my shared object.

Follow up:

While this worked, at least in a test environment, after the comments above from Jim Cownie we decided to just disable OpenMP support from our library for now.

superstator
  • 3,005
  • 1
  • 33
  • 43