| View previous topic :: View next topic |
| How long until hardened and toolchain will produce a hardened gcc4? |
| 1 year |
|
23% |
[ 40 ] |
| 5 years |
|
20% |
[ 35 ] |
| 10 years |
|
7% |
[ 13 ] |
| lifetime |
|
4% |
[ 8 ] |
| eternity |
|
44% |
[ 76 ] |
|
| Total Votes : 172 |
|
| Author |
Message |
R.Smith
Tux's lil' helper
Joined: 20 Nov 2005
Posts: 131
Location: Caerdydd, Cymru.
|
 Posted: Sat May 10, 2008 5:37 pm Post subject: |
 |
|
Thank you, guys, for all the hard work that you're doing. I've been wanting to have a hardened Gentoo install for ages but was put off by the lack of progress in its development. It's good to see more life in the project again.  |
|
| Back to top |
|
 |
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Sat May 10, 2008 6:41 pm Post subject: |
|
|
| R.Smith wrote: | | Thank you, guys, for all the hard work that you're doing. I've been wanting to have a hardened Gentoo install for ages but was put off by the lack of progress in its development. It's good to see more life in the project again. |
Thanks
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
qjim
n00b
Joined: 10 May 2008
Posts: 23
|
| Posted: Sun May 11, 2008 12:47 pm Post subject: |
|
|
I have a problem with hardened tools. Probably big problem.
1) add "=sys-devel/gcc-4.2.3* ~x86" "=sys-libs/glibc-2.7* ~x86" to /etc/portage/package.keywords (I have k7)
2) upgrade to gcc-4.2.3 ang glibc-2.7-r2 (both from portage and unhardened)
3) set new unhardened gcc-4.2.3 as default compiler
4) change my profile to profiles/default/linux/x86/2008.0/desktop
------- start hardened experiment -------
5) change PKGDIR in /etc/make.conf to new location for hardened packages
6) copy sys-devel/gcc and sys-libs/glibc dirs from portage/ebuilds to new zorry overlay (/usr/local/portage/zorry)
7) copy all files from http://www.ume.nu/~zorry/filer/Gentoo-hardened/portage/ over this zorry overlay
8) append 'PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /usr/local/portage/zorry"' to /etc/make.conf
9) ebuild digest new ebuilds in zorry overlay
10) remove hardened flags from profiles/default/linux/package.use.mask
11) emerge --oneshot --buildpkgonly sys-devel/binutils sys-devel/gcc sys-libs/glibc
12) emerge --oneshot --usepkgonly sys-devel/binutils sys-devel/gcc sys-libs/glibc
13) set new hardened gcc-4.2.3-r2 as default compiler (toolschain was build by unhardened gcc/glibc)
Without separate --buildpkgonly/--usepkgonly emerge ended with errors as "compiler can't make exe ..." and "your linker don't support version ..."
14) add CFLAGS="${CFLAGS} -D_FORTIFY_SOURCE=2" to /etc/make.conf
15) emerge --oneshot sys-devel/binutils sys-devel/gcc sys-libs/glibc ... ERR
Binutils and gcc were OK, but glibc compilation ended with error "compiler don't support PIE" or something similar.
GCC SPECS from glibc environment was "/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/hardenednopie.specs:nossp.specs:nofortify.specs"
I decided repeat gcc compilation:
16) emerge --oneshot sys-devel/gcc ... OK
17) reset new hardened gcc-4.2.3-r2 as default compiler
And compile glibc with new gcc
18) emerge --oneshot sys-libs/glibc ... OK
GCC SPECS from glibc environment changed to "/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/hardened.specs:nossp.specs:nofortify.specs"
Specs is now hardened.specs but still nossp, nofortify
19) reset new hardened gcc-4.2.3-r2 as default compiler again
Because specs are nossp.specs:nofortify.specs I decided repeat whole compilation again.
20) emerge --oneshot sys-devel/binutils sys-devel/gcc sys-libs/glibc ... OK
After that all emerge still ending with message:
* Messages for package sys-libs/glibc-2.7-r2:
* Hardened compiler filtered -fstack-protector - GCC_SPECS set to /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/hardened.specs:nossp.specs
* Hardened compiler filtered -D_FORTIFY_SOURCE=2 - GCC_SPECS set to /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/hardened.specs:nossp.specs:nofortify.specs
Zorry's test.c compiled by this "hardened" gcc:
| Code: | $ gcc -Wall -O0 test.c -o test
$ ./test $(perl -e 'print "A"x100')
Your first argument was: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
*** stack smashing detected ***: test - terminated
test: stack smashing attack in function <unknown> - terminated
Report to http://bugs.gentoo.org/
(SIGKILL)
|
| Code: | $ gcc -Wall -O2 test.c -o test
$ ./test $(perl -e 'print "A"x100')
*** buffer overflow detected ***: ./test terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x48)[0xa7ef4e68]
/lib/libc.so.6[0xa7ef2240]
/lib/libc.so.6(__strcpy_chk+0x49)[0xa7ef16a9]
./test(main+0x54)[0xa7f98714]
/lib/libc.so.6(__libc_start_main+0xe0)[0xa7e30400]
./test[0xa7f985f1]
======= Memory map: ========
a7e0d000-a7e17000 r-xp 00000000 08:26 25534562 /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libgcc_s.so.1
a7e17000-a7e18000 r--p 00009000 08:26 25534562 /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libgcc_s.so.1
a7e18000-a7e19000 rw-p 0000a000 08:26 25534562 /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libgcc_s.so.1
a7e19000-a7e1a000 rw-p a7e19000 00:00 0
a7e1a000-a7f4d000 r-xp 00000000 08:25 6355 /lib/libc-2.7.so
a7f4d000-a7f4f000 r--p 00132000 08:25 6355 /lib/libc-2.7.so
a7f4f000-a7f50000 rw-p 00134000 08:25 6355 /lib/libc-2.7.so
a7f50000-a7f54000 rw-p a7f50000 00:00 0
a7f7b000-a7f7c000 r-xp a7f7b000 00:00 0 [vdso]
a7f7c000-a7f96000 r-xp 00000000 08:25 40611 /lib/ld-2.7.so
a7f96000-a7f97000 r--p 0001a000 08:25 40611 /lib/ld-2.7.so
a7f97000-a7f98000 rw-p 0001b000 08:25 40611 /lib/ld-2.7.so
a7f98000-a7f99000 r-xp 00000000 08:28 7844 /home/devel/test
a7f99000-a7f9a000 r--p 00000000 08:28 7844 /home/devel/test
a7f9a000-a7f9b000 rw-p 00001000 08:28 7844 /home/devel/test
a9a1b000-a9a3c000 rw-p a9a1b000 00:00 0 [heap]
afd82000-afd98000 rw-p affea000 00:00 0 [stack]
(SIGABRT)
|
Have you an idea what is wrong? Or better, why? |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Sun May 11, 2008 1:40 pm Post subject: |
|
|
| qjim wrote: | I have a problem with hardened tools. Probably big problem.
1) add "=sys-devel/gcc-4.2.3* ~x86" "=sys-libs/glibc-2.7* ~x86" to /etc/portage/package.keywords (I have k7)
2) upgrade to gcc-4.2.3 ang glibc-2.7-r2 (both from portage and unhardened)
3) set new unhardened gcc-4.2.3 as default compiler
4) change my profile to profiles/default/linux/x86/2008.0/desktop
------- start hardened experiment -------
5) change PKGDIR in /etc/make.conf to new location for hardened packages
6) copy sys-devel/gcc and sys-libs/glibc dirs from portage/ebuilds to new zorry overlay (/usr/local/portage/zorry)
7) copy all files from http://www.ume.nu/~zorry/filer/Gentoo-hardened/portage/ over this zorry overlay
 append 'PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /usr/local/portage/zorry"' to /etc/make.conf
9) ebuild digest new ebuilds in zorry overlay
10) remove hardened flags from profiles/default/linux/package.use.mask
11) emerge --oneshot --buildpkgonly sys-devel/binutils sys-devel/gcc sys-libs/glibc
12) emerge --oneshot --usepkgonly sys-devel/binutils sys-devel/gcc sys-libs/glibc
13) set new hardened gcc-4.2.3-r2 as default compiler (toolschain was build by unhardened gcc/glibc)
Without separate --buildpkgonly/--usepkgonly emerge ended with errors as "compiler can't make exe ..." and "your linker don't support version ..."
14) add CFLAGS="${CFLAGS} -D_FORTIFY_SOURCE=2" to /etc/make.conf
15) emerge --oneshot sys-devel/binutils sys-devel/gcc sys-libs/glibc ... ERR
Binutils and gcc were OK, but glibc compilation ended with error "compiler don't support PIE" or something similar.
GCC SPECS from glibc environment was "/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/hardenednopie.specs:nossp.specs:nofortify.specs"
I decided repeat gcc compilation:
16) emerge --oneshot sys-devel/gcc ... OK
17) reset new hardened gcc-4.2.3-r2 as default compiler
And compile glibc with new gcc
1 emerge --oneshot sys-libs/glibc ... OK
GCC SPECS from glibc environment changed to "/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/hardened.specs:nossp.specs:nofortify.specs"
Specs is now hardened.specs but still nossp, nofortify
19) reset new hardened gcc-4.2.3-r2 as default compiler again
Because specs are nossp.specs:nofortify.specs I decided repeat whole compilation again.
20) emerge --oneshot sys-devel/binutils sys-devel/gcc sys-libs/glibc ... OK
After that all emerge still ending with message:
* Messages for package sys-libs/glibc-2.7-r2:
* Hardened compiler filtered -fstack-protector - GCC_SPECS set to /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/hardened.specs:nossp.specs
* Hardened compiler filtered -D_FORTIFY_SOURCE=2 - GCC_SPECS set to /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/hardened.specs:nossp.specs:nofortify.specs
Zorry's test.c compiled by this "hardened" gcc:
| Code: | $ gcc -Wall -O0 test.c -o test
$ ./test $(perl -e 'print "A"x100')
Your first argument was: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
*** stack smashing detected ***: test - terminated
test: stack smashing attack in function <unknown> - terminated
Report to http://bugs.gentoo.org/
(SIGKILL)
|
| Code: | $ gcc -Wall -O2 test.c -o test
$ ./test $(perl -e 'print "A"x100')
*** buffer overflow detected ***: ./test terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x48)[0xa7ef4e68]
/lib/libc.so.6[0xa7ef2240]
/lib/libc.so.6(__strcpy_chk+0x49)[0xa7ef16a9]
./test(main+0x54)[0xa7f98714]
/lib/libc.so.6(__libc_start_main+0xe0)[0xa7e30400]
./test[0xa7f985f1]
======= Memory map: ========
a7e0d000-a7e17000 r-xp 00000000 08:26 25534562 /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libgcc_s.so.1
a7e17000-a7e18000 r--p 00009000 08:26 25534562 /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libgcc_s.so.1
a7e18000-a7e19000 rw-p 0000a000 08:26 25534562 /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libgcc_s.so.1
a7e19000-a7e1a000 rw-p a7e19000 00:00 0
a7e1a000-a7f4d000 r-xp 00000000 08:25 6355 /lib/libc-2.7.so
a7f4d000-a7f4f000 r--p 00132000 08:25 6355 /lib/libc-2.7.so
a7f4f000-a7f50000 rw-p 00134000 08:25 6355 /lib/libc-2.7.so
a7f50000-a7f54000 rw-p a7f50000 00:00 0
a7f7b000-a7f7c000 r-xp a7f7b000 00:00 0 [vdso]
a7f7c000-a7f96000 r-xp 00000000 08:25 40611 /lib/ld-2.7.so
a7f96000-a7f97000 r--p 0001a000 08:25 40611 /lib/ld-2.7.so
a7f97000-a7f98000 rw-p 0001b000 08:25 40611 /lib/ld-2.7.so
a7f98000-a7f99000 r-xp 00000000 08:28 7844 /home/devel/test
a7f99000-a7f9a000 r--p 00000000 08:28 7844 /home/devel/test
a7f9a000-a7f9b000 rw-p 00001000 08:28 7844 /home/devel/test
a9a1b000-a9a3c000 rw-p a9a1b000 00:00 0 [heap]
afd82000-afd98000 rw-p affea000 00:00 0 [stack]
(SIGABRT)
|
Have you an idea what is wrong? Or better, why? |
4 If i get it u are using no hardened profile? profile/hardened/linux/x86/2008.0/desktop is the hardened profile.
11-13 have not test --buildpkgonly i did only do emerge --oneshot binutils gcc glibc
14 u don't need to add it to the flag it is in the specs files
Glibc do not support to build with ssp and fortify_source yet.
The test is working for u so u have a working toolchain
Thanks for testing.
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
Xake
Guru
Joined: 11 Feb 2004
Posts: 588
Location: Göteborg, the rainy part of scandinavia
|
| Posted: Mon May 12, 2008 7:02 pm Post subject: |
|
|
| qjim wrote: | I have a problem with hardened tools. Probably big problem.
1) add "=sys-devel/gcc-4.2.3* ~x86" "=sys-libs/glibc-2.7* ~x86" to /etc/portage/package.keywords (I have k7)
2) upgrade to gcc-4.2.3 ang glibc-2.7-r2 (both from portage and unhardened)
3) set new unhardened gcc-4.2.3 as default compiler
4) change my profile to profiles/default/linux/x86/2008.0/desktop |
Why?
You would be better off just setting up the overlay at once and then unmask/compile gcc. That is what I did.
Oh, and you can fetch my git. It currently works as zorrys does (with some small exceptions we are working on). I use it in two chroots and on one live (EXPERIMENTAL) system and no bigger problems currently (arw going to add packages that needs masking/patches as I find them. |
|
| Back to top |
|
|
qjim
n00b
Joined: 10 May 2008
Posts: 23
|
| Posted: Mon May 12, 2008 10:08 pm Post subject: |
|
|
Why? Because it was done on live system, not in chroot. So I need working toolchain in case of some troubles (and they actually happened). Return back from glibc-2.7 to glibs-2.6 isn't wonderful idea. And what is better gcc for compilation gcc-4.2.3 than gcc-4.2.3?
I'm not still sure, that I really have full working hardened toolchain.
| Code: | $ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/specs
Target: i686-pc-linux-gnu
Configured with: /usr/vartmp/portage/sys-devel/gcc-4.2.3-r2/work/gcc-4.2.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.2.3 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.3/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.2.3 (Gentoo Hardened 4.2.3-r2 p1.0, ssp-builtin, pie-9.0.9)
|
| Code: | $ gcc -dumpspecs
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
*asm_debug:
%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}
*asm_final:
*asm_options:
%a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}
*invoke_as:
%{!S:-o %|.s |
as %(asm_options) %|.s %A }
*cpp:
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
*cpp_options:
%(cpp_unique_options) %1 %{m*} %{std*&ansi&trigraphs} %{W*&pedantic*} %{w} %{f*} %{g*:%{!g0:%{!fno-working-directory:-fworking-directory}}} %{O*} %{undef} %{save-temps:-fpch-preprocess}
*cpp_debug_options:
%{d*}
*cpp_unique_options:
%{C|CC:%{!E:%eGCC does not support -C or -CC without -E}} %{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{MD|MMD:%{o*:-MQ %*}}}}} %{remap} %{g3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %{fmudflap:-D_MUDFLAP -include mf-runtime.h} %{fmudflapth:-D_MUDFLAP -D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:%W{o*}}
*trad_capable_cpp:
cc1 -E %{traditional|ftraditional|traditional-cpp:-traditional-cpp}
*cc1:
%(cc1_cpu) %{profile:-p} %{!D__KERNEL__: %(cc1_pie) %(cc1_ssp) %(cc1_fofy) }
*cc1_options:
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %{shared:%{static|pie|fPIE|fpie|fno-PIC|fno-pic:%e-shared and -static|pie|fPIE|fpie|fno-PIC|fno-pic are incompatible}} %{pie:%{static|pg|p|profile:%e-pie and -static|pg|p|profile are incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*} %{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}%{!c:%{!S:-auxbase %b}} %{g*} %{O*} %{W*&pedantic*} %{w} %{std*&ansi&trigraphs} %{v:-version} %{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{--help:--help} %{--target-help:--target-help} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*} %{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants} %{coverage:-fprofile-arcs -ftest-coverage}
*cc1plus:
*link_gcc_c_sequence:
%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}
*link_ssp:
%{fstack-protector:}
*endfile:
%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s} %{shared:crtendS.o%s} %{!shared:%(endfile_pie)} crtn.o%s
*link:
%{!static:--eh-frame-hdr} -m %(link_emulation) %{shared:-shared} %{!shared: %{!ibcs: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker %(dynamic_linker)}} %{static:-static}}}
*lib:
%{pthread:-lpthread} %{shared:-lc} %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}}
*mfwrap:
%{static: %{fmudflap|fmudflapth: --wrap=malloc --wrap=free --wrap=calloc --wrap=realloc --wrap=mmap --wrap=munmap --wrap=alloca} %{fmudflapth: --wrap=pthread_create}} %{fmudflap|fmudflapth: --wrap=main}
*mflib:
%{fmudflap|fmudflapth: -export-dynamic}
*link_gomp:
*libgcc:
%{static|static-libgcc:-lgcc -lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --as-needed -lgcc_s --no-as-needed}%{shared-libgcc:-lgcc_s%{!shared: -lgcc}}}}
*startfile:
%{!shared: %{pg|p|profile:gcrt1.o%s} %{!pg:%{!p:%{!profile:%(crtfile_pie)}}} } crti.o%s %{shared:crtbeginS.o%s} %{!shared:%(startfile_pie_t)}
*switches_need_spaces:
*cross_compile:
0
*version:
4.2.3
*multilib:
. ;
*multilib_defaults:
*multilib_extra:
*multilib_matches:
*multilib_exclusions:
*multilib_options:
*linker:
collect2
*link_libgcc:
%D
*md_exec_prefix:
*md_startfile_prefix:
*md_startfile_prefix_1:
*startfile_prefix_spec:
*sysroot_spec:
--sysroot=%R
*sysroot_suffix_spec:
*sysroot_hdrs_suffix_spec:
*asm_pie:
%{pie:-K PIC}
*cc1_ssp:
*cc1_ssp_all:
*cc1_pie:
%{pie:-fPIE}
*crtfile_pie:
%{static:crt1.o%s;pie:Scrt1.o%s;:crt1.o%s}
*endfile_pie:
%{pie:crtendS.o%s;:crtend.o%s}
*startfile_pie:
%{static:crtbegin.o%s;pie:crtbeginS.o%s;:crtbegin.o%s}
*startfile_pie_t:
%{static:crtbeginT.o%s;pie:crtbeginS.o%s;:crtbegin.o%s}
*link_relro:
%{norelro:}
*link_now:
%{nonow:}
*link_pie:
%{pie:-pie}
*cc1_cpu:
%{!mtune*: %{m386:mtune=i386 %n`-m386' is deprecated. Use `-march=i386' or `-mtune=i386' instead.
} %{m486:-mtune=i486 %n`-m486' is deprecated. Use `-march=i486' or `-mtune=i486' instead.
} %{mpentium:-mtune=pentium %n`-mpentium' is deprecated. Use `-march=pentium' or `-mtune=pentium' instead.
} %{mpentiumpro:-mtune=pentiumpro %n`-mpentiumpro' is deprecated. Use `-march=pentiumpro' or `-mtune=pentiumpro' instead.
} %{mcpu=*:-mtune=%* %n`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
}} %<mcpu=* %{mintel-syntax:-masm=intel %n`-mintel-syntax' is deprecated. Use `-masm=intel' instead.
} %{mno-intel-syntax:-masm=att %n`-mno-intel-syntax' is deprecated. Use `-masm=att' instead.
}%{march=native:%<march=native %:local_cpu_detect(arch) %{!mtune=*:%<mtune=native %:local_cpu_detect(tune)}} %{mtune=native:%<mtune=native %:local_cpu_detect(tune)}
*link_emulation:
elf_i386
*dynamic_linker:
%{muclibc:%{mglibc:%e-mglibc and -muclibc used together}/lib/ld-uClibc.so.0;:/lib/ld-linux.so.2}
*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S: %(linker) %l %(link_pie) %(link_relro) %(link_now) %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}} %{static:} %{L*} %(mfwrap) %(link_libgcc) %o %{fopenmp:%:include(libgomp.spec)%(link_gomp)} %(mflib) %{fprofile-arcs|fprofile-generate|coverage:-lgcov} %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}} %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}
|
Where is cc1_ssp or cc1_fofy?
cc1_pie is
but in pie.specs is something very different:
| Code: | | %{pie:-fPIE} %{!pie: %{!fpic:%{!fPIC:%{!fpie:%{!fPIE: %{!fno-pic:%{!fno-PIC:%{!fno-pie:%{!fno-PIE: %{!shared: %{!nopie:-fPIE} } }}}} }}}} } |
cc1_ssp is empty
but in ssp.specs is:
| Code: | | %{!nostdlib:%{!nodefaultlibs: %{!fno-stack-protector:%{!fstack-protector:%{!fstack-protector-all:-fstack-protector %(cc1_ssp_all) }}} }} |
Same with cc1_fofy which is actually nonexistent in dumpspecs
This is very very confusing for someone with no previous experience with hardened gcc-4.
Maybe Zorry or Xake can write some sticky warning and explanation on this issues. |
|
| Back to top |
|
|
qjim
n00b
Joined: 10 May 2008
Posts: 23
|
| Posted: Mon May 12, 2008 10:21 pm Post subject: |
|
|
I recompile all packages with new toolchain and when I check environment file I found this:
| Code: | FEATURES='buildpkg ccache collision-protect distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch userpriv usersandbox'
FLTK_DOCDIR=/usr/share/doc/fltk-1.1.7-r2/html
GCC_SPECS=
GDK_USE_XFT=1
GENERATION=2
|
Actually I found empty GCC_SPECS in every package environment which I checked.
Is it normal? |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Mon May 12, 2008 11:07 pm Post subject: |
|
|
| qjim wrote: | Why? Because it was done on live system, not in chroot. So I need working toolchain in case of some troubles (and they actually happened). Return back from glibc-2.7 to glibs-2.6 isn't wonderful idea. And what is better gcc for compilation gcc-4.2.3 than gcc-4.2.3?
I'm not still sure, that I really have full working hardened toolchain.
| Code: | $ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/specs
Target: i686-pc-linux-gnu
Configured with: /usr/vartmp/portage/sys-devel/gcc-4.2.3-r2/work/gcc-4.2.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.2.3 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.2.3/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.2.3 (Gentoo Hardened 4.2.3-r2 p1.0, ssp-builtin, pie-9.0.9)
|
| Code: | $ gcc -dumpspecs
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
*asm_debug:
%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}
*asm_final:
*asm_options:
%a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}
*invoke_as:
%{!S:-o %|.s |
as %(asm_options) %|.s %A }
*cpp:
%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
*cpp_options:
%(cpp_unique_options) %1 %{m*} %{std*&ansi&trigraphs} %{W*&pedantic*} %{w} %{f*} %{g*:%{!g0:%{!fno-working-directory:-fworking-directory}}} %{O*} %{undef} %{save-temps:-fpch-preprocess}
*cpp_debug_options:
%{d*}
*cpp_unique_options:
%{C|CC:%{!E:%eGCC does not support -C or -CC without -E}} %{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{MD|MMD:%{o*:-MQ %*}}}}} %{remap} %{g3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %{fmudflap:-D_MUDFLAP -include mf-runtime.h} %{fmudflapth:-D_MUDFLAP -D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:%W{o*}}
*trad_capable_cpp:
cc1 -E %{traditional|ftraditional|traditional-cpp:-traditional-cpp}
*cc1:
%(cc1_cpu) %{profile:-p} %{!D__KERNEL__: %(cc1_pie) %(cc1_ssp) %(cc1_fofy) }
*cc1_options:
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %{shared:%{static|pie|fPIE|fpie|fno-PIC|fno-pic:%e-shared and -static|pie|fPIE|fpie|fno-PIC|fno-pic are incompatible}} %{pie:%{static|pg|p|profile:%e-pie and -static|pg|p|profile are incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*} %{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}%{!c:%{!S:-auxbase %b}} %{g*} %{O*} %{W*&pedantic*} %{w} %{std*&ansi&trigraphs} %{v:-version} %{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{--help:--help} %{--target-help:--target-help} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*} %{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants} %{coverage:-fprofile-arcs -ftest-coverage}
*cc1plus:
*link_gcc_c_sequence:
%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}
*link_ssp:
%{fstack-protector:}
*endfile:
%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s} %{shared:crtendS.o%s} %{!shared:%(endfile_pie)} crtn.o%s
*link:
%{!static:--eh-frame-hdr} -m %(link_emulation) %{shared:-shared} %{!shared: %{!ibcs: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker %(dynamic_linker)}} %{static:-static}}}
*lib:
%{pthread:-lpthread} %{shared:-lc} %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}}
*mfwrap:
%{static: %{fmudflap|fmudflapth: --wrap=malloc --wrap=free --wrap=calloc --wrap=realloc --wrap=mmap --wrap=munmap --wrap=alloca} %{fmudflapth: --wrap=pthread_create}} %{fmudflap|fmudflapth: --wrap=main}
*mflib:
%{fmudflap|fmudflapth: -export-dynamic}
*link_gomp:
*libgcc:
%{static|static-libgcc:-lgcc -lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --as-needed -lgcc_s --no-as-needed}%{shared-libgcc:-lgcc_s%{!shared: -lgcc}}}}
*startfile:
%{!shared: %{pg|p|profile:gcrt1.o%s} %{!pg:%{!p:%{!profile:%(crtfile_pie)}}} } crti.o%s %{shared:crtbeginS.o%s} %{!shared:%(startfile_pie_t)}
*switches_need_spaces:
*cross_compile:
0
*version:
4.2.3
*multilib:
. ;
*multilib_defaults:
*multilib_extra:
*multilib_matches:
*multilib_exclusions:
*multilib_options:
*linker:
collect2
*link_libgcc:
%D
*md_exec_prefix:
*md_startfile_prefix:
*md_startfile_prefix_1:
*startfile_prefix_spec:
*sysroot_spec:
--sysroot=%R
*sysroot_suffix_spec:
*sysroot_hdrs_suffix_spec:
*asm_pie:
%{pie:-K PIC}
*cc1_ssp:
*cc1_ssp_all:
*cc1_pie:
%{pie:-fPIE}
*crtfile_pie:
%{static:crt1.o%s;pie:Scrt1.o%s;:crt1.o%s}
*endfile_pie:
%{pie:crtendS.o%s;:crtend.o%s}
*startfile_pie:
%{static:crtbegin.o%s;pie:crtbeginS.o%s;:crtbegin.o%s}
*startfile_pie_t:
%{static:crtbeginT.o%s;pie:crtbeginS.o%s;:crtbegin.o%s}
*link_relro:
%{norelro:}
*link_now:
%{nonow:}
*link_pie:
%{pie:-pie}
*cc1_cpu:
%{!mtune*: %{m386:mtune=i386 %n`-m386' is deprecated. Use `-march=i386' or `-mtune=i386' instead.
} %{m486:-mtune=i486 %n`-m486' is deprecated. Use `-march=i486' or `-mtune=i486' instead.
} %{mpentium:-mtune=pentium %n`-mpentium' is deprecated. Use `-march=pentium' or `-mtune=pentium' instead.
} %{mpentiumpro:-mtune=pentiumpro %n`-mpentiumpro' is deprecated. Use `-march=pentiumpro' or `-mtune=pentiumpro' instead.
} %{mcpu=*:-mtune=%* %n`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
}} %<mcpu=* %{mintel-syntax:-masm=intel %n`-mintel-syntax' is deprecated. Use `-masm=intel' instead.
} %{mno-intel-syntax:-masm=att %n`-mno-intel-syntax' is deprecated. Use `-masm=att' instead.
}%{march=native:%<march=native %:local_cpu_detect(arch) %{!mtune=*:%<mtune=native %:local_cpu_detect(tune)}} %{mtune=native:%<mtune=native %:local_cpu_detect(tune)}
*link_emulation:
elf_i386
*dynamic_linker:
%{muclibc:%{mglibc:%e-mglibc and -muclibc used together}/lib/ld-uClibc.so.0;:/lib/ld-linux.so.2}
*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S: %(linker) %l %(link_pie) %(link_relro) %(link_now) %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}} %{static:} %{L*} %(mfwrap) %(link_libgcc) %o %{fopenmp:%:include(libgomp.spec)%(link_gomp)} %(mflib) %{fprofile-arcs|fprofile-generate|coverage:-lgcov} %{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}} %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}
|
Where is cc1_ssp or cc1_fofy?
cc1_pie is
but in pie.specs is something very different:
| Code: | | %{pie:-fPIE} %{!pie: %{!fpic:%{!fPIC:%{!fpie:%{!fPIE: %{!fno-pic:%{!fno-PIC:%{!fno-pie:%{!fno-PIE: %{!shared: %{!nopie:-fPIE} } }}}} }}}} } |
cc1_ssp is empty
but in ssp.specs is:
| Code: | | %{!nostdlib:%{!nodefaultlibs: %{!fno-stack-protector:%{!fstack-protector:%{!fstack-protector-all:-fstack-protector %(cc1_ssp_all) }}} }} |
Same with cc1_fofy which is actually nonexistent in dumpspecs
This is very very confusing for someone with no previous experience with hardened gcc-4.
Maybe Zorry or Xake can write some sticky warning and explanation on this issues. |
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/specs (Hardened spece file)
From bug#149649
Well, we could go patching what -dumpspecs does, but I don't think it's a good
idea. It moves us further from upstream when we don't need to, and means you
can't get the builtin specs without unsetting GCC_SPECS and more disruptively
deleting ${LIBPATH}/specs. -dumpspecs has _always_ provided the builtin specs,
regardless of whether there's a ${LIBPATH}/specs file or any -specs directives
on the compiler invocation. It's designed to tell you about the compiler
driver, not what specs the compilation will actually use.
Glibc x.x won't build with ssp or fortify_source.
From http://github.com/Xake/toolchain-overlay/tree/master/pieworld.README
glibc:
------
1) Built with PIE-default, SSP off, RELRO and BIND_NOW
SSP-default messes up the dependencies, in different ways on different arches; changes
to glibc would be too invasive for easy maintenance.
2) Non-PIC crtstuff built -fno-PIE (crt1.o - note; crtn.o, crti.o, Scrt1.o all built -fPIC)
3) Make pic-default configure check ignore -fPIE.
4) Link all apps PIE, adjust TLS initialisation to avoid using the TLS before it's ready
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1)
Last edited by zorry on Mon May 12, 2008 11:39 pm; edited 1 time in total |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Mon May 12, 2008 11:32 pm Post subject: |
|
|
| qjim wrote: | I recompile all packages with new toolchain and when I check environment file I found this:
| Code: | FEATURES='buildpkg ccache collision-protect distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch userpriv usersandbox'
FLTK_DOCDIR=/usr/share/doc/fltk-1.1.7-r2/html
GCC_SPECS=
GDK_USE_XFT=1
GENERATION=2
|
Actually I found empty GCC_SPECS in every package environment which I checked.
Is it normal? |
GCC_SPECS is not set in /etc/env.d/gcc/x86-pc-linux-gnu-4.2.3
gcc will use /usr/lib/gcc/x86-pc-linux-gnu/4.2.3/specs (hardened specs)
and then if GCC_SPECS is set it vill use thet.
look att vanilla.
The test case is working for u.
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Wed May 14, 2008 3:37 am Post subject: |
|
|
Update on testing gcc 3.x
Have a working chroot now
ebuild unpack OK
ebuild compile OK
ebuild install OK
emerge gcc OK
TEST
ssp OK
nossp OK
pie OK
RELORO OK
Thanks stevel for the help.
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Thu May 15, 2008 9:42 am Post subject: |
|
|
We will have a trac up and runing soon.
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Thu May 15, 2008 11:01 pm Post subject: |
|
|
What do we need on the trac?
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
Xake
Guru
Joined: 11 Feb 2004
Posts: 588
Location: Göteborg, the rainy part of scandinavia
|
| Posted: Fri May 16, 2008 10:40 am Post subject: |
|
|
| zorry wrote: | | What do we need on the trac? |
Instructions instructions and lots of instructions.
Then we need tickets and lots of bugreports.
Browsing git is nice.
More then that, I can't really say. My thought is to have it as a central point we can refer to if/when questions arises, but also a cntral point to keep track of what have been fixed and what problems have been identified. Browsing a forum-thread is not optimal for those kind of things. |
|
| Back to top |
|
|
Sadako
Advocate
Joined: 05 Aug 2004
Posts: 3792
Location: sleeping in the bathtub
|
| Posted: Fri May 16, 2008 3:55 pm Post subject: |
|
|
Would it be feasible to have the eclasses from the overlay renamed (ie toolchain2.eclass rather than overriding the toolchain.eclass in portage)?
The reason I ask is I need to run `emerge --regen` after each `emerge --sync`, otherwise any use of emerge is painfully slow, and --regen usually takes up to 30 minutes.
If it's okay to have everything in portage proper use the eclasses in portage, and have the ebuilds in the overlay use only the eclasses from the overlay, then would there be any problem?
Or am I the only one having this issue?
_________________
"You have to invite me in" |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Fri May 16, 2008 4:21 pm Post subject: |
|
|
| Hopeless wrote: | Would it be feasible to have the eclasses from the overlay renamed (ie toolchain2.eclass rather than overriding the toolchain.eclass in portage)?
The reason I ask is I need to run `emerge --regen` after each `emerge --sync`, otherwise any use of emerge is painfully slow, and --regen usually takes up to 30 minutes.
If it's okay to have everything in portage proper use the eclasses in portage, and have the ebuilds in the overlay use only the eclasses from the overlay, then would there be any problem?
Or am I the only one having this issue? |
raises hand
me too 
it always takes ages until portage starts to emerge 
so that's the solution: | Code: | | emerge --sync && emerge --regen |
?!
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa
Hardcore Gentoo Linux user since 2004  |
|
| Back to top |
|
|
Xake
Guru
Joined: 11 Feb 2004
Posts: 588
Location: Göteborg, the rainy part of scandinavia
|
| Posted: Fri May 16, 2008 4:26 pm Post subject: |
|
|
| Hopeless wrote: | Would it be feasible to have the eclasses from the overlay renamed (ie toolchain2.eclass rather than overriding the toolchain.eclass in portage)?
The reason I ask is I need to run `emerge --regen` after each `emerge --sync`, otherwise any use of emerge is painfully slow, and --regen usually takes up to 30 minutes.
If it's okay to have everything in portage proper use the eclasses in portage, and have the ebuilds in the overlay use only the eclasses from the overlay, then would there be any problem?
Or am I the only one having this issue? |
You are not the only one having that issue, but since we needs to alterate the behavior of some functions in flag-o-matic.eclass like everything filtering -fPIE, -fstack-protector and -D_FORTIFY_SOURCE=2 if we rename the eclasses we also then need to alter every ebuild/eclass/script using flag-o-matic to use the right eclass.
And since you have to run emerge --regen for that eclass there is simply no meaning having a diffrent name on the other two eclasses. |
|
| Back to top |
|
|
Xake
Guru
Joined: 11 Feb 2004
Posts: 588
Location: Göteborg, the rainy part of scandinavia
|
| Posted: Fri May 16, 2008 4:29 pm Post subject: |
|
|
| Note to self: toolchain.eclass currently does not work with gcc-4.2.x-ebuilds in the tree as the toolchain wants to patch in a patch that does not exists in portage. Trying to figure out if there is an better way then simply "use hardened" filtering... |
|
| Back to top |
|
|
Sadako
Advocate
Joined: 05 Aug 2004
Posts: 3792
Location: sleeping in the bathtub
|
| Posted: Fri May 16, 2008 4:34 pm Post subject: |
|
|
| Xake wrote: | | Hopeless wrote: | Would it be feasible to have the eclasses from the overlay renamed (ie toolchain2.eclass rather than overriding the toolchain.eclass in portage)?
The reason I ask is I need to run `emerge --regen` after each `emerge --sync`, otherwise any use of emerge is painfully slow, and --regen usually takes up to 30 minutes.
If it's okay to have everything in portage proper use the eclasses in portage, and have the ebuilds in the overlay use only the eclasses from the overlay, then would there be any problem?
Or am I the only one having this issue? |
You are not the only one having that issue, but since we needs to alterate the behavior of some functions in flag-o-matic.eclass like everything filtering -fPIE, -fstack-protector and -D_FORTIFY_SOURCE=2 if we rename the eclasses we also then need to alter every ebuild/eclass/script using flag-o-matic to use the right eclass.
And since you have to run emerge --regen for that eclass there is simply no meaning having a diffrent name on the other two eclasses. |
Ah, fair enough, I was just hoping that the modifications were only needed by the ebuilds in the overlay, but if they're really needed by everything which inherits those eclasses then you are of course right, there'd be no point in doing what I suggested.
Glad to know I'm not the only one experiencing this, though.
_________________
"You have to invite me in" |
|
| Back to top |
|
|
Sadako
Advocate
Joined: 05 Aug 2004
Posts: 3792
Location: sleeping in the bathtub
|
| Posted: Fri May 16, 2008 4:39 pm Post subject: |
|
|
| kernelOfTruth wrote: | | Hopeless wrote: | Would it be feasible to have the eclasses from the overlay renamed (ie toolchain2.eclass rather than overriding the toolchain.eclass in portage)?
The reason I ask is I need to run `emerge --regen` after each `emerge --sync`, otherwise any use of emerge is painfully slow, and --regen usually takes up to 30 minutes.
If it's okay to have everything in portage proper use the eclasses in portage, and have the ebuilds in the overlay use only the eclasses from the overlay, then would there be any problem?
Or am I the only one having this issue? |
raises hand
me too
it always takes ages until portage starts to emerge
so that's the solution: | Code: | | emerge --sync && emerge --regen |
?! |
Yeah, I've been using that (emereg --regen) for ages 'cause I've been using kevquinn's pieworld overlay all along...
_________________
"You have to invite me in" |
|
| Back to top |
|
|
Xake
Guru
Joined: 11 Feb 2004
Posts: 588
Location: Göteborg, the rainy part of scandinavia
|
| Posted: Fri May 16, 2008 11:59 pm Post subject: |
|
|
| kernelOfTruth wrote: | | Hopeless wrote: | Would it be feasible to have the eclasses from the overlay renamed (ie toolchain2.eclass rather than overriding the toolchain.eclass in portage)?
The reason I ask is I need to run `emerge --regen` after each `emerge --sync`, otherwise any use of emerge is painfully slow, and --regen usually takes up to 30 minutes.
If it's okay to have everything in portage proper use the eclasses in portage, and have the ebuilds in the overlay use only the eclasses from the overlay, then would there be any problem?
Or am I the only one having this issue? |
raises hand
me too
it always takes ages until portage starts to emerge
so that's the solution: | Code: | | emerge --sync && emerge --regen |
?! |
Does not portage shout that at you loud and annoying everytime you do something with emerge that you should do "...emerge --regen becouse of..." and a long list of eclasses from other overlays? |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Sat May 17, 2008 2:40 pm Post subject: |
|
|
| zorry wrote: | Update on testing gcc 3.x
Have a working chroot now
ebuild unpack OK
ebuild compile OK
ebuild install OK
emerge gcc OK
TEST
ssp OK
nossp OK
pie OK
RELORO OK
Thanks stevel for the help. |
emerge -e world OK
Upgrade from gcc 3.x to 4.x
change to 3.x vanilla
USE="-Hardened" emerge gcc-4.2.3-r2 OK
change profile to 2008 hardened
change to gcc 4.2.3
emerge --oneshot binutils gcc glibc OK
emerge -e world compiling now
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
Xake
Guru
Joined: 11 Feb 2004
Posts: 588
Location: Göteborg, the rainy part of scandinavia
|
| Posted: Sat May 17, 2008 6:46 pm Post subject: |
|
|
Saw that pappy have finally found the time creating something for GXS. Now we only have to wait and see if he really does something with it...
Personally I have thoughts about looking into what patch fixes the __guard and grab it from him. |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Sat May 17, 2008 7:28 pm Post subject: |
|
|
| Xake wrote: | Saw that pappy have finally found the time creating something for GXS. Now we only have to wait and see if he really does something with it...
Personally I have thoughts about looking into what patch fixes the __guard and grab it from him. |
Yes have see he is doing some thing. But have't seen any patch or somting yet from him.
Gcc 3.x to 4.x works
What is left for us before we try to do some bug's?
Gcc 4.x defult profile and split_specs thet is left in toolchain?
Any thing more?
Working on trac now.
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
zorry
Developer
Joined: 30 Mar 2008
Posts: 380
Location: Umeå The north part of scandinavia
|
| Posted: Wed May 28, 2008 1:40 am Post subject: |
|
|
Gcc 4.2.4 is in portage.
Bug#149649 is no more
Are we going to open a new bug for hardened gcc 4.x toolchain?
_________________
gcc version 6.1.0 (Gentoo Hardened 6.1.0 p1.1) |
|
| Back to top |
|
|
Xake
Guru
Joined: 11 Feb 2004
Posts: 588
Location: Göteborg, the rainy part of scandinavia
|
| Posted: Wed May 28, 2008 10:20 am Post subject: |
|
|
| zorry wrote: | Gcc 4.2.4 is in portage.
Bug#149649 is no more
Are we going to open a new bug for hardened gcc 4.x toolchain? |
No new bug for hardened gcc-4 until we have something hardened have had a chance to look at and have given us their input on.
And maybe let toolchain have a look at it also.
Then comes the testing and telling people to break their systems for us! |
|
| Back to top |
|
|
|
Gentoo Chat
