make[1]: Entering directory '/var/tmp/portage/sys-boot/lilo-24.2/work/lilo-24.2/src' x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -fno-pic -Os -Wall `if [ -f /usr/include/linux/version.h ]; then echo -DHAS_VERSION_H; fi` `if [ -f /usr/include/libdevmapper.h ]; then echo -DHAS_LIBDEVMAPPER_H; fi` -DLILO=0xbb920890 `( if [ -r $DESTDIR/etc/lilo.defines ]; then cat $DESTDIR/etc/lilo.defines; else echo -DBDATA -DDSECS=3 -DEVMS -DIGNORECASE -DLVM -DNOKEYBOARD -DONE_SHOT -DPASS160 -DREISERFS -DREWRITE_TABLE -DSOLO_CHAIN -DVERSION -DVIRTUAL -DMDPRAID ; fi ) | sed 's/-D/-DLCF_/g'` -Wl,-O1 -Wl,--as-needed -DSHS_MAIN -o version common.c /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /var/tmp/portage/sys-boot/lilo-24.2/temp/cc98Dqi5.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /var/tmp/portage/sys-boot/lilo-24.2/temp/cc98Dqi5.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status make[1]: *** [Makefile:258: version] Error 1 ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0-desktop-gnome-libressl_20170611-103213 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.3.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 (fallback) [3] jython2.7 (fallback) java-config: The following VMs are available for generation-2: *) IcedTea JDK 3.4.0 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-8 system-vm
Created attachment 476674 [details] emerge-info.txt
Created attachment 476676 [details] emerge-history.txt
Created attachment 476678 [details] environment
Created attachment 476680 [details] etc.portage.tbz2
Created attachment 476682 [details] sys-boot:lilo-24.2:20170616-031332.log
Created attachment 476684 [details] temp.tbz2
Ran into this when rebuilding my dev box using gcc-7.1.0 and the 17.0 profiles. As the error message indicates, a temporary workaround is to add -fPIC to CFLAGS just for sys-boot/lilo, and it'll complete the build. The resulting executable runs well enough to modify the MBR to boot, though I have not yet tried natively booting this system after its rebuild.
I've been bitten by this through a hardened profile. Removing # hardened automatic PIC plus PIE building should be suppressed # because of assembler instructions that cannot be compiled HARDENED_CFLAGS=$(test-flags-CC -fno-pic -nopie) seems to produce a working lilo. Tony, what was the exact reason here - is there any chance it is an old surviving relict that can be removed?
This also fails with gcc-6.4. Shouldn't this block gcc-6.4 stabilization (bug#630844) then? Thanks.
Hi, I have just encountered the same problem. The latest Gentoo news recommends to move to a new profile and rebuild everything (emerge -e @world). Unfortunately lilo rebuild does not work (I even tried to add -fPIC to CFLAGS, CXXFLAGS and LDFLAGS, but maybe I am doing something wrong, because -fno-pic is always added). Any workarounds? When this will be fixed? Thanks
Hi, I have the exact same problem as the previous commenter. I tried everything but it look like our CFLAGS are completely ignored. It's stuck to -fno-pic and it's set to -01 instead of -02 in my make.conf.
Hi, sorry my bad English. lilo-24.0-r1 also does not compile (gcc 6.4, profile 17.0). To create a new bug or continue here?
I have the same problem. As suggested previously, my workaround was to patch the ebuild file to remove all references to HARDENED_CFLAGS: --- lilo-24.0-r1.ebuild 2017-02-28 19:50:50.000000000 +0000 +++ lilo-24.0-r1.ebuild 2017-12-02 12:01:14.605432719 +0000 @@ -49,10 +49,6 @@ # lilo needs this. bug #140209 export LC_ALL=C - # hardened automatic PIC plus PIE building should be suppressed - # because of assembler instructions that cannot be compiled PIC - HARDENED_CFLAGS=$(test-flags-CC -fno-pic -nopie) - # we explicitly prevent the custom CFLAGS for stability reasons if use static; then local target=alles @@ -60,7 +56,7 @@ local target=all fi - emake CC="$(tc-getCC) ${LDFLAGS} ${HARDENED_CFLAGS}" ${target} || die + emake CC="$(tc-getCC) ${LDFLAGS}" ${target} || die } src_install() { This allows lilo-24.0-r1 to build and "emerge -e @world" to finish.
(In reply to Petr Cerny [:hrosik] from comment #8) > Tony, what was the exact reason here - is > there any chance it is an old surviving relict that can be removed? It is legacy code from a long long time ago, when this was the correct thing to do. My apologies for missing this bug report for so long. If I don't get around to it quickly, any dev reading this, please go ahead and commit the removal to all LILO ebuilds to restore full functionality. Sorry.
(In reply to Tony Vroon from comment #14) > (In reply to Petr Cerny [:hrosik] from comment #8) > > Tony, what was the exact reason here - is > > there any chance it is an old surviving relict that can be removed? > > It is legacy code from a long long time ago, when this was the correct thing > to do. My apologies for missing this bug report for so long. If I don't get > around to it quickly, any dev reading this, please go ahead and commit the > removal to all LILO ebuilds to restore full functionality. > Sorry. It broke one of my builds so I took care of it.
*** Bug 640232 has been marked as a duplicate of this bug. ***
