Depending on the prior version of hardened-gcc that is active, it currently might need to be installed twice to get working results. Noticed this when upgrading a system that hadn't been touched since right after the move-propolice-to-glibc patch.
Prior version was hardened-gcc-22.214.171.124-r1 at the start of this exercise:
emerge sync ; emerge hardened-gcc ; etc-update ; hcc -a ; emerge portage
At the last step there it fails with:
Checking libc version... /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: cannot open crt1S.o: No such file or directory
so now i do:
emerge hardened-gcc ; hcc -a ; emerge portage
works just fine now. so time to test my theory:
emerge =sys-devel/hardened-gcc-126.96.36.199-r1 ; etc-update ; hcc -a ; emerge hardened-gcc ; etc-update ; hcc -a ; emerge portage
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000008048580
Checking libc version... /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../../../i686-pc-linux-gnu/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000008048250
different this time, but at least proves that the libraries compiled within the hcc ebuild are affected by the previously active version, which was never an issue when it was just manipulating text files. now that its actually compiling things, care should be taken to ensure they get built with an appropriate set of configs.
anything you want me to do now?
i have experienced problems with the glibc provided Scrt1.o regarding ISC bind compiling and similar programs where -pie is used to create binaries that do not contain a main function for whatsoever reason
The gotoff->got fix is in ~arch glibc now so that should nip the ISC
Upgrade woes are going to be a problem. Some users are gonna get peeved
and just write the solution off as non functional, while others will
resort to reporting bugs and using the work around and some will just
never figure it out and may leave gentoo all together.
'symbol _start; defaulting' is going to continue to bite us in the butt
till new stages are rolled. zhen tells me it might be to late to do
anything about it. If that the case then we are stuck with this bug
popping up from time to time till 2004.1
this bug describes a problem known as "specs file truncating" by the wrong hardened-gcc shell script editing a specs file it is not known to be able to edit properly.
in the future, hardened-gcc will be blocked by profile and forced uninstallation as well as recent gcc versions with hardened support for sys-devel/gcc will be coming soon
The whole problem of updating and downgrading hardened-gcc in disjunction with gcc cannot be solved by an uncoupled hardened-gcc shell script without much efforts of detecting current gcc version and specs.
maintaining such a logic would be more hassle than it would bring advantages.
for this reason solar and i created a native gcc patch which can do the job more appropriately and avoid such "truncated" specs files in the future.