Summary: | dev-lang/whitespace-0.3: unrecognized command line option ‘-nopie’ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Jan Matějka (RETIRED) <yac> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | haskell, slyfox |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge log |
Description
Toralf Förster
2015-02-23 13:11:52 UTC
Please post the full build log. Works for me. Any idea where is the -nopie coming from? * Using cabal-1.20.0.2. * Prepending /usr/lib64/ghc-7.6.3 to LD_LIBRARY_PATH /usr/bin/ghc -package Cabal-1.20.0.2 --make /var/tmp/portage/dev-lang/whitespace-0.3/work/WSpace/Setup.lhs -dynamic -o setup [1 of 1] Compiling Main ( /var/tmp/portage/dev-lang/whitespace-0.3/work/WSpace/Setup.lhs, /var/tmp/portage/dev-lang/whitespace-0.3/work/WSpace/Setup.o ) Linking setup ... ./setup configure --ghc --prefix=/usr --with-compiler=/usr/bin/ghc --with-hc-pkg=/usr/bin/ghc-pkg --prefix=/usr --libdir=/usr/lib64 --libsubdir=whitespace-0.3/ghc-7.6.3 --datadir=/usr/share/ --datasubdir=whitespace-0.3/ghc-7.6.3 --ghc-option=-optl-Wl,-O1 --ghc-option=-optl -Wl,--as-needed --disable-executable-stripping --docdir=/usr/share/doc/whitespace-0.3 --verbose --sysconfdir=/etc --disable-library-stripping Configuring WSpace-0.3... ... Created attachment 397432 [details] emerge log (In reply to Jan Matějka from comment #1) > Please post the full build log. Works for me. Any idea where is the -nopie > coming from? There're much more package affected, so probably an eclass/ issue ? Nevertheless build is attached. tinderbox@tor-relay ~/amd64-unstable.kde/var/log/portage $ grep -l "error: unrecognized command line option ‘-nopie’" * dev-haskell:base-unicode-symbols-0.2.2.4:20150222-102153.log dev-haskell:byteable-0.1.1:20150222-102021.log dev-haskell:generic-deriving-1.7.0:20150222-094620.log dev-haskell:ghc-paths-0.1.0.9:20150222-044715.log dev-haskell:haskeline-0.7.1.3:20150222-081217.log dev-haskell:list-0.5.1:20150222-102953.log dev-haskell:readline-1.0.3.0:20150222-054626.log dev-haskell:regex-base-0.93.2-r1:20150222-052923.log dev-haskell:system-filepath-0.4.13.1:20150222-040731.log dev-haskell:utf8-string-0.3.8:20150222-082242.log dev-haskell:xml-1.3.13:20150222-100234.log dev-lang:whitespace-0.3:20150223-130058.log Weird. My impression is that the only place where the -nopie flag can come from is flag-o-matic.eclass _filter-hardened function. Also parts of your report mention it is hardened system but your profile seems to be non-hardened. What is your selected gcc? I'm running root@deathstar # eselect profile list | grep '*' [19] hardened/linux/amd64 * root@deathstar # gcc-config -l | grep '*' [6] x86_64-pc-linux-gnu-4.8.3 * and have no issue. I run 6 different chroot images at a host in parallel for QA purpose. The host itself is hardened (and therefore in few rare cases breakspackages). The images itself are stable/unstable + hardened/regular. Please post your /usr/bin/ghc (it's a script) from that machine. (In reply to Sergei Trofimovich from comment #5) > Please post your /usr/bin/ghc (it's a script) from that machine. tinderbox@tor-relay ~ $ cat amd64-unstable.kde/usr/bin/ghc #!/bin/sh exedir="/usr/lib64/ghc-7.8.4/bin" exeprog="ghc-stage2" executablename="$exedir/$exeprog" datadir="/usr/share" bindir="/usr/bin" topdir="/usr/lib64/ghc-7.8.4" executablename="$exedir/ghc" exec "$executablename" -B"$topdir" -optc-nopie -optl-nopie -optc-fno-stack-protector ${1+"$@"} (In reply to Toralf Förster from comment #6) > (In reply to Sergei Trofimovich from comment #5) > > Please post your /usr/bin/ghc (it's a script) from that machine. > > tinderbox@tor-relay ~ $ cat amd64-unstable.kde/usr/bin/ghc > #!/bin/sh > exedir="/usr/lib64/ghc-7.8.4/bin" > exeprog="ghc-stage2" > executablename="$exedir/$exeprog" > datadir="/usr/share" > bindir="/usr/bin" > topdir="/usr/lib64/ghc-7.8.4" > executablename="$exedir/ghc" > exec "$executablename" -B"$topdir" -optc-nopie -optl-nopie > -optc-fno-stack-protector ${1+"$@"} OK, GHC biary was build on hardened host. Does gcc on that environment understand -nopie? $ echo "int a = 0;" > a.c $ gcc -c a.c -nopie For me this test works only on hardened toolchain. This -nopie is injected by ghc ebuild: gcc-specs-pie && append-ghc-cflags persistent compile link -nopie Which means that either ghc binary or used toolchain is inappropriate for this setup. *** Bug 541020 has been marked as a duplicate of this bug. *** well, the host itself gives : tinderbox@tor-relay ~ $ echo "int a = 0;" > a.c tinderbox@tor-relay ~ $ gcc -c a.c -nopie but chroot'ing into the image (which is not hardened, just unstable) gives : tinderbox@tor-relay ~ $ sudo ./chr.sh amd64-unstable.kde tor-relay / # su - tor-relay ~ # echo "int a = 0;" > a.c tor-relay ~ # gcc -c a.c -nopie gcc: error: unrecognized command line option ‘-nopie’ (In reply to Toralf Förster from comment #9) > well, the host itself gives : > > tinderbox@tor-relay ~ $ echo "int a = 0;" > a.c > tinderbox@tor-relay ~ $ gcc -c a.c -nopie > > but chroot'ing into the image (which is not hardened, just unstable) gives : > > tinderbox@tor-relay ~ $ sudo ./chr.sh amd64-unstable.kde > tor-relay / # su - > tor-relay ~ # echo "int a = 0;" > a.c > tor-relay ~ # gcc -c a.c -nopie > gcc: error: unrecognized command line option ‘-nopie’ Do you happen to share binkpks between the hardened/nonhardened chroots? eix ^ghc$ in broken chroot should show installed binpkg as {tbz2} (In reply to Sergei Trofimovich from comment #10) > Do you happen to share binkpks between the hardened/nonhardened chroots? no, each chroot is independend from each other except - sharing the 2 directories /distfiles and /package.mask/ (In reply to Toralf Förster from comment #11) > (In reply to Sergei Trofimovich from comment #10) > > Do you happen to share binkpks between the hardened/nonhardened chroots? > > no, each chroot is independend from each other except - sharing the 2 > directories /distfiles and /package.mask/ It clearly looks as some obscure environment leak. I'm afraid you'll have to research yourself how '-nopie' got to /usr/bin/ghc on that toolchain. It should be easy to discover by adding some einfo around call to ghc .ebuild: gcc-specs-pie && append-ghc-cflags persistent compile link -nopie [gcc-specs-pie() lives in eclass/toolchain-funcs.eclass] and running emerge on ghc ebuild. |