1 |
The code is not ready for any sort of public consumption yet. Please |
2 |
hold off on sending it to any mailing lists yet. |
3 |
It does not use the DYNAMIC_LINKER correctly yet, it only handles i386, |
4 |
and the macro's fully override the built in gcc which we don't want. |
5 |
I'll give you another update over the weekened which can be tested with |
6 |
uClibc. |
7 |
|
8 |
|
9 |
On Fri, 2004-01-23 at 04:43, Peter S. Mazinger wrote: |
10 |
> Some comments regarding uclibc: |
11 |
> |
12 |
> On 22 Jan 2004, Ned Ludd wrote: |
13 |
> |
14 |
> > pappy, |
15 |
> > |
16 |
> > I'm CC: peter so he can get a heads up on what we are thinking. |
17 |
> > |
18 |
> > Attachments included. |
19 |
> > |
20 |
> > This is also building on your box. |
21 |
> > In the screen chroot but it's not in the not in an overlay. |
22 |
> > |
23 |
> > Also pappy to make Martin happy could you confirm the guard scan takes |
24 |
> > place every single time gcc is built. You suggested the idea to him so a |
25 |
> > patch to have the ebuild behave the way you said in a previous mail |
26 |
> > would be great. The base-system herd wants this so -r5 can be pushed to |
27 |
> > stable. I also want see 3.3.2 go stable because it will allow us get |
28 |
> > everybody on the same page with basic toolchain pie support. |
29 |
> > |
30 |
> > ... |
31 |
> > * Done with patching |
32 |
> > * Applying |
33 |
> > gcc331-pp-fixup.patch... [ ok ] |
34 |
> > * Applying |
35 |
> > protector.dif... [ ok ] |
36 |
> > * Applying |
37 |
> > gcc-3.3.2-gentoo-branch-update-20031218-pie-ssp.patch... [ ok ] |
38 |
> |
39 |
> This patch has fixed crt1.o, uclibc works with pie also for crt0.o. One |
40 |
> solution would be to patch uclibc so, that it copies crt0.o as crt1.o (as |
41 |
> I did with Scrt1.o for the case CTOR_DTOR is not defined), then no change |
42 |
> is needed to work with uclibc. I'll check with Erik if he will do the |
43 |
> change to uclibc, if not this patch has to be somehow adapted to check for |
44 |
> uClibc-config.h file. |
45 |
> |
46 |
> > * Applying |
47 |
> > gcc332-gentoo-branding.patch... [ ok ] |
48 |
> > |
49 |
> > * This sys-libs/glibc has __guard object and __stack_smash_handler |
50 |
> > functions |
51 |
> > * scanning the system for binaries with __guard - this may take 5-10 |
52 |
> > minutes |
53 |
> > * Please do not press ctrl-C or ctrl-Z during this period - it will |
54 |
> > continue |
55 |
> > |
56 |
> > * Scanning system for __guard@GCC symbols... |
57 |
> > * Scanning 01 of 10 /lib... |
58 |
> > * Scanning 02 of 10 /usr/lib... |
59 |
> |
60 |
> The ssp_scan is easy to implement for uClibc (check for ld-uClibc.so.0 |
61 |
> presence, and check libc.so.0), but how do we know, if uClibc is main |
62 |
> libc, should we check first for ld-uClibc.so, then if it is present, |
63 |
> check if also libc.so.6 is present, if yes, then glibc is main libc, else |
64 |
> uClibc. The check is needed because propolice is an option (yet) in |
65 |
> uClibc, so there could be versions not having __guard/__smash... |
66 |
> |
67 |
> Peter, |
68 |
-- |
69 |
Ned Ludd <solar@g.o> |
70 |
Gentoo Linux Developer |