ocioarchive.dir/main.cpp.o: relocation R_X86_64_32 against `.bss' can not be used when making a PIE object #1857
Comments
|
From the logs the objects are compiled like this: Then linked with So at first glance there is nothing asking for PIE as called by our CMake ... Which version of Fedora are you building for I know some older versions had bugs related to building of static objects and then linking with PIE. So there could be an interaction with the hardened linker specs wanting to use PIE but the matching requirement is not set in the gcc config - I would have thought this is unlikely but possible. https://fedoraproject.org/wiki/Changes/Harden_All_Packages I'm led to believe fedora uses flag injection on the command line rather than building the compiler and linker with matching defaults based on some clang forum posts (don't you just love the Internet for sources of Truth) The other option could be which version of cmake are you using as that can effect behaviour we require 3.13 which is just the wrong side of https://cmake.org/cmake/help/latest/policy/CMP0083.html#policy:CMP0083 which could be why the behaviour is triggering. |
|
Assuming your CMake version is actually newer, you could perhaps try update the cmake_minimum_version() to 3.15 in the top level CMakeLists.txt and If I'm reading the CMake docs right add: I (We) picked 3.15 as that aligns with OIIO as well as the ASWF sample template. Now it is possible we will need to be much more granular with things to make the actual executable targets correct on Fedora, but That would be my first steps, if I had a Fedora build host to try it on. |
|
Shame on me for not specifying but in general unless otherwise specified I'm talking about Fedora Rawhide (rolling devel branch). I can still compile 2.2.1 without issue. |
|
So I tried building in a fedora docker container and building it as-is without the rpm build environment I don't get the problem, so I guess it has something to do with that. Approximate Dockerfile Next step would be to try build with the fedora rpmbuild setup and or the CFLAGS etc |
|
So by setting the environment variables for the compiler and linker flags outside of cmake I was able to recreate the error. After attempting to fix it with my suggestions, they do not work for this issue. The reason is that my suggestions are nominally correct for when a project internally wants to generate PIE/PIC objects, however in this case, as the linker/compiler flags are being modified outside the knowledge of CMake, our project files do not "know" to compile the executable object files with the appropriate flags. So the question is what to do, long term we could look to add an option for distributions to choose to add the appropriate target properties to our executables (or choose to build them with position independence for all platforms), then my fixes might be the right suggestion, to ensure the linker gets passed the appropriate flags In the short term you can brute force the build to generate PIC code for all targets by adding Note that this will force PIC flags for all objects which isn't quite the same as using PIE for the executable objects, which may add additional overhead vs using the PIE flags, but I assume Fedora is wanting to prioritise the potential security benefits over any performance loss of allowing relocatable executables. This should have no impact on the code in the shared library as by definition they already needed/are compiled as PIC. |
|
Indeed, much of the flags being set are for security/hardening along with things like link time optimization. Not sure if this helps but here's the Don't ask me to unwind the logic here :) |
|
Sure, I'm suggesting you need to add Alternately you could try get the logic in the cc1 hardening option changed to add the pie option correctly, but that would have far greater consequences to the whole OS build, definitely not for OCIO to wag that dog. I believe other distros solve this by building the compiler with pie by default for all code generation, rather than doing the option mangling |
|
I tried that and got a strange result I've never seen before: Apparently the debug symbols can't be found now? |
|
and the CMAKE_BUILD_TYPE is set to RelWithDebInfo ? Apologies, but I'm just not familiar with Fedora's build setup to replicate it. |
|
Success! I haven't had to set that option in ages as the inserted Fedora flags usually take care of it. |
|
For some reason only i686 failed: I don't technically have to build for i686 at this point but wanted to check if this is easily fixable first. |
|
Well the use of rbx should be for 64 bit platform, that suggests maybe the line Line 185 in 87126fa Can you see what value that had in your cmake cache? I suspect this maybe something to do with cross compiling... does you build system pass in a tool chain file to set that value when building for i686 ? |
|
Looks like the issue that was fixed in #1842 ? |
|
Ah yes, didn't check to see the difference between the HEAD and the 2.3.0 version tag |
|
I used the pull request as a patch and that fixed it. Thanks! |
carolalynn
added
the
Build Issue
New compile error on Fedora with 2.3.0:
Full log here:
https://kojipkgs.fedoraproject.org//work/tasks/2223/106302223/build.log
The text was updated successfully, but these errors were encountered: