manylinux
manylinux copied to clipboard
pypa
Added position independent code flag for python compilation.
In using the manylinux image to create wheels, the package I am compiling creates a shared library from the static python libraries in the image. Without the position independent code flag (-fPIC) I get the following error:
/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: buck-out/gen/third-party/python/python3.8_lib/libpython3.8.a(myreadline.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
Adding the flag fixes this compilation issue. Since, as noted in https://github.com/pypa/manylinux/pull/1250, the static libs remain in compressed form unless explicitly unpacked, this should have minimal affect on most users.
Let me know if I can provide any clarification on this PR.
A bit of background on the real use-case would be nice since it seems to differ from the one that lead to #1250
The PR does not change a thing regarding size on x86_64 so I think adding the flag is ok overall as -fPIC code can be linked in every case.
@pperanich, please address the comment about openssl build.
As the one who made the original PR to include the static libs, this PR seems like a very dangerous idea!
The only use case for including the static libs is to embed the interpreter into an executable. There are special linker mechanisms used when producing such an executable that make the symbols from libpython available to loaded extension modules.
Enabling -fPIC will allow libpython to be linked into a module library, which is exactly what people should not do. So it just opens up ways for people to shoot themselves into the foot.
Is there a legitimate use case for embedding the interpreter into a shared library? How could this even work, how can a library make its symbols globally available for subsequently dynamically loaded extension modules?
@pperanich Having had a cursory look at your use case, your project seems to be producing an extension module, in which case linking with libpython on Linux is not correct and would produce modules that are not compatible between different Python installations.
You should instead fix the build system not to link with libpython. I don't have the correct linker flags handy, but they should not be hard to find.
Per @rdb comment, the use-case involved seems to be an invalid one, so closing this PR.