export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie ? 2016-10-31 10:21 GMT+01:00 Ian Campbell <i...@debian.org>:
> 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 > >
