Issue 36718: Python 2.7 compilation fails on AMD64 Ubuntu Shared 2.7 buildbot with: relocation R_X86_64_PC32 against symbol ... can not be used ... (original) (raw)
Created on 2019-04-25 13:32 by vstinner, last changed 2022-04-11 14:59 by admin. This issue is now closed.
https://buildbot.python.org/all/#/builders/139/builds/251 Example: building 'time' extension gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/include/x86_64-linux-gnu -I/usr/local/include -I/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Include -I/srv/buildbot/buildarea/2.7.bolen-ubuntu/build -c /srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Modules/timemodule.c -o build/temp.linux-x86_64-2.7-pydebug/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Modules/timemodule.o gcc -pthread -shared build/temp.linux-x86_64-2.7-pydebug/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Modules/timemodule.o -L/usr/lib/x86_64-linux-gnu -L/usr/local/lib -L. -lm -lpython2.7 -o build/lib.linux-x86_64-2.7-pydebug/time.so /usr/local/lib/libpython2.7.a(posixmodule.o): In function `posix_tmpnam': /srv/buildbot/Python-2.7.16/./Modules/posixmodule.c:7648: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp' /usr/local/lib/libpython2.7.a(posixmodule.o): In function `posix_tempnam': /srv/buildbot/Python-2.7.16/./Modules/posixmodule.c:7595: warning: the use of `tempnam' is dangerous, better use `mkstemp' /usr/bin/ld: /usr/local/lib/libpython2.7.a(ceval.o): relocation R_X86_64_PC32 against symbol `PyFunction_Type' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status It seems to be a regression caused by my change, commit f4edd39017a211d4544570a1e2ac2110ef8e51b4, PR 12875 for bpo-28552.
@David Bolen: Would you mind to have a look at this issue on your buildbot? I'm not sure that the regression is caused by my commit, since the command lines are the same in the previous build 250: building 'time' extension gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/include/x86_64-linux-gnu -I/usr/local/include -I/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Include -I/srv/buildbot/buildarea/2.7.bolen-ubuntu/build -c /srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Modules/timemodule.c -o build/temp.linux-x86_64-2.7-pydebug/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Modules/timemodule.o gcc -pthread -shared build/temp.linux-x86_64-2.7-pydebug/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Modules/timemodule.o -L/usr/lib/x86_64-linux-gnu -L/usr/local/lib -L. -lm -lpython2.7 -o build/lib.linux-x86_64-2.7-pydebug/time.so
Yes, it appears most likely to be the worker environment. I did upgrade the kernel in between builds 250 (good) and 251 (bad), but reverting that still fails, even with the same commit as in build 250. My current suspicion is that a test I did recently with a static 2.7.16 build is influencing the buildbot build process (which might explain why the error seems to involve an -fPIC mismatch in a library). Not sure how yet though.
Ok, I've resolved this, and the linker errors did actually point at the root issue. They show trying to link extensions against /usr/local/lib/libpython2.7.a which was my test static build of 2.7.16. Arguably this seems an issue in the buildbot build process in that it doesn't sandbox extension building to force linking to the python library being built rather than a random system library, but I can't see spending any time on that. I've purged the 2.7.16 files from the /usr/local tree and things seem to be back to normal I've started a new run for the failing build.
