Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)
Hi,
I maintain qcontrol[0] which builds on armel and armhf only (it's a
tool specific to certain NAS machines). It links a version against
liblua statically for use in a udeb (the resulting binary is dynamic,
it is only liblua5.1 which is linked statically).
It seems that on armhf my latest upload has failed to build for reasons
which look to be related to the PIE by default transition[1]:
cc -Wl,-z,relro -g qcontrol.o system.o qnap-pic.o ts209.o ts219.o ts409.o ts41x.o evdev.o a125.o synology.o /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/liblua5.1.a -lpthread -lm -ldl -o qcontrol-static
/usr/bin/ld: /usr/lib/arm-linux-gnueabihf/liblua5.1.a(lapi.o): relocation R_ARM_THM_MOVW_ABS_NC against `luaO_nilobject_' can not be used when making a shared object; recompile with -fPIC
I've checked the wiki and the recent '"PIE by default" transition is
underway -- wiki needs updating' thread on d-devel but I'm none the
wiser on what my next course of action should be.
Should I be filing a bug against liblua asking for specific changes?
asking for a binNMU? Making some change to qcontrol's build (maybe
-fno-pic or -fno-pie, I've played with this a little with no luck so
far, I'll keep poking at it though)?
I don't see any preexisting bugs against liblua5.1 around the need for
changes or rebuild.
Thanks for any advice,
Ian.
[0] https://tracker.debian.org/pkg/qcontrol
[1] https://buildd.debian.org/status/fetch.php?pkg=qcontrol&arch=armhf&ver=0.5.5-1&stamp=1477849051
[2] https://wiki.debian.org/Hardening/PIEByDefaultTransition
Reply to: