Public bug reported: reglookup 1.0.1+svn296-2 has been stuck in stonking-proposed for ~346 days. update_excuses reports:
missing build on amd64: libregfi-dev, libregfi1t64, python3-pyregfi, reglookup, reglookup-doc (from 1.0.1+svn287-10) missing build on amd64v3: libregfi-dev, libregfi1t64, reglookup (from 1.0.1+svn287-10) Build log (amd64): https://launchpad.net/ubuntu/+source/reglookup/1.0.1+svn296-2/+build/32793594 Failure, when linking the shared library: gcc -o lib/libregfi.so.1.0.1 -fPIE -pie -Wl,-Bsymbolic-functions ... -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now -shared -Wl,-soname=libregfi.so.1 lib/regfi.os lib/winsec.os ... /usr/bin/x86_64-linux-gnu-ld.bfd: /tmp/cc97Ox7x.ltrans0.ltrans.o: relocation R_X86_64_PC32 against symbol `stderr@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld.bfd: final link failed: bad value scons: *** [lib/libregfi.so.1.0.1] Error 1 Cause: - debian/patches/fix-install.patch (updated in svn296-2 for the hppa fix, Debian #1114771) changes SConstruct to: cflags += '-fPIE ' + os.environ.get('CFLAGS', ...) linkflags = '-fPIE -pie ' + os.environ.get('LDFLAGS', ...) (previously linkflags was "-fPIC " + LDFLAGS). LINKFLAGS applies to every link done by the SCons environment, including env.SharedLibrary(), so libregfi.so is linked with "-fPIE -pie ... -shared". - The .os objects themselves are correctly compiled with -fPIC (SCons appends it for shared objects). Without LTO the link flags don't affect code generation, so this works in Debian, which doesn't use LTO by default (Debian has binaries on all architectures). - Ubuntu builds with -flto=auto by default. With LTO, the real code generation happens at link time, using the PIC mode from the link command line, i.e. -fPIE. The library code is then generated as PIE (non-PIC) code, and ld refuses it for a shared object. - The previous version in stonking (svn287-10) linked with -fPIC and built fine. Debian / upstream status: - No Debian bug for this (it doesn't happen without LTO). - The SConstruct change is Debian's own (patch marked Forwarded: not-needed). Suggested direction (to be done by whoever picks this up): - Proper fix: don't use the PIE link flags for the shared library. E.g. in fix-install.patch, keep LINKFLAGS for programs only and give SharedLibrary its own flags (env.SharedLibrary(..., LINKFLAGS=os.environ.get('LDFLAGS', ...)), or SHLINKFLAGS), or drop '-fPIE -pie' from linkflags entirely and let dpkg-buildflags (hardening=+all already gives PIE through gcc's defaults) handle it. Check the hppa case from #1114771 still makes sense with the change. - Quick alternative: export DEB_BUILD_MAINT_OPTIONS = hardening=+all optimize=-lto in debian/rules. - Test-build in stonking (amd64 is enough to reproduce), check the python3-pyregfi/reglookup binaries still work, upload as an Ubuntu delta and forward the SConstruct fix to Debian, since linking a shared library with -pie is wrong regardless of LTO. ** Affects: reglookup (Ubuntu) Importance: Undecided Status: New ** Tags: ftbfs update-excuse ** Tags added: update-excuse ** Tags added: ftbfs -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2170337 Title: reglookup FTBFS in stonking: libregfi.so linked with -fPIE -pie, breaks with LTO (recompile with -fPIC) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/reglookup/+bug/2170337/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
