I'll attach list of ebuilds that still reference hardened-gcc.
Created attachment 31209 [details] list of ebuilds
yes, the plan is clear from now on: replace has_version hardened-gcc && filter-flags with a pure call to the filter-flags logic so that it does not depend on hardened-gcc any more and the eclass can do the job of emitting the exclude chain arguments to the compiler CFLAGS and LDFLAGS sinc. Alex
all ebuilds have been cleared from occurrences of hardened-gcc and complimentary logic has been added, sinc. Alex
Can you tidy up the commented code in sys-fs/dosfstools please?
pappy, The check in dosfstools is incorrect. Please test these things before you make cvs commits This is why I had to force sed love on the Makefile before. The safe thing to probably do here is to force -fno-PIC/-fno-pic into the makefile either as a patch or a sed hack. ------------------------------------------------------ simple dosfstools # emerge dosfstools Calculating dependencies ...done! >>> emerge (1 of 1) sys-fs/dosfstools-2.10 to / >>> Downloading http://open-systems.ufl.edu/mirrors/gentoo/distfiles/dosfstools-2.10.src.tar.gz --14:23:41-- http://open-systems.ufl.edu/mirrors/gentoo/distfiles/dosfstools-2.10.src.tar.gz => `/usr/portage/distfiles/dosfstools-2.10.src.tar.gz' Resolving open-systems.ufl.edu... 128.227.74.66 Connecting to open-systems.ufl.edu[128.227.74.66]:80... connected. HTTP request sent, awaiting response... 200 OK Length: 66,759 [application/x-tar] 100%[================================================================================================================>] 66,759 --.--K/s 14:23:42 (462.46 KB/s) - `/usr/portage/distfiles/dosfstools-2.10.src.tar.gz' saved [66759/66759] >>> md5 src_uri ;-) dosfstools-2.10.src.tar.gz >>> Unpacking source... >>> Unpacking dosfstools-2.10.src.tar.gz to /var/tmp/portage/dosfstools-2.10/work * Applying errno.patch... [ ok ] * Applying dosfstools-2.10-2.6.headers.patch... [ ok ]>>> Source unpacked. make -C mkdosfs all make[1]: Entering directory `/var/tmp/portage/dosfstools-2.10/work/dosfstools-2.10/mkdosfs' gcc -O2 -fomit-frame-pointer -Wall -c mkdosfs.c -o mkdosfs.o mkdosfs.c: In function `_llseek': mkdosfs.c:110: error: can't find a register in class `BREG' while reloading `asm' make[1]: *** [mkdosfs.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/dosfstools-2.10/work/dosfstools-2.10/mkdosfs' make: *** [all] Error 2 !!! ERROR: sys-fs/dosfstools-2.10 failed. !!! Function src_compile, Line 36, Exitcode 2 !!! (no error message)
Created attachment 31379 [details, diff] dosfstools-2.10.ebuild.diff pappy this compiles for me. arch x86 is (optional?)
check your disk ops or I will hunt you down. sed ... || die
Created attachment 31384 [details, diff] dosfstools-2.10.ebuild.diff (2) this also "compiles" for me with new and improved mr_bones code :)
yeah, I like it. someone add this to the ebuild howto. ;-)
According to the recent discussion on -dev, the system should only and purely depend on the recognition of global CFLAGS by the respective Makefiles. This means, in the case of dosfstools, that SED logic to manipulate the Makefiles is deprecated. Does dosfstools contain Makefiles that do not recognize CFLAGS given to it? But we learned that only the global CFLAGS should be the way for exclusion logic to be introduced. So i added filter-flags -fPIC and removed the SED logic depending on the existence of hardened-gcc. In a perfect world, as we live in such a perfect world, this works. This is what i learned through the discussion on the mailing lists. Do you really consider me a stupid fool now or someone who does not play nice and according to the rules? I do not think this needs to become a confrontation or argument about the needed technical changes. The mailing list wanted it to work this way. My opinion: if the dosfstools package does not recognize global CFLAGS and act accordingly to our changes to the CFLAGS, the package maintainer should always feel free to correct the Makefile. Well, the hardened team can even support those efforts. But it is not my job to deal with broken packages only because i am introducing a default PIE SSP compiler to Gentoo Hardened. And i doubt that a hardened machine will ever see the dosfstools packages getting compiled on a mission critical dns, mail or web server. Make your choice, it is yours. Sincerely, Alex
this is a compromise we could suggest to the base-system people for improving the behaviour of dosfstools in respect to hardened gcc compiling: src_compile() { HARDENED_CFLAGS="`test_flag -fno-pic` `test_flag -nopie` `test_flag -fno-stack-protector`" # this package does *not* play well with optimisations # please dont change to: make OPTFLAGS="${CFLAGS}" make OPTFLAGS="${HARDENED_CFLAGS}" || die } tell me if you want that to show up in all dosfstools packages, it is similar logic like you can find in GRUB and LILO ebuilds Alex
hardened-gcc looks to be gone to me so can this bug be closed?
Ok, seems like this is cleared up. One final note: USE="hardened" emerge gcc obsoletes hardened-gcc At least, according to Pappy. ;-) Thanks for taking care of this.
