1 |
Hello all, Hello Preston, |
2 |
|
3 |
just adding my 2 cents. I'm in the process to emerge a system based on |
4 |
the gcc 3.0.4 as discussed earlier in this threat. |
5 |
Having the glibc and gcc3 compiled with the gcc 2.95 of the stage1 iso |
6 |
image made me worried after your post. |
7 |
And indeed, the mini compiler of the iso refused to accept the |
8 |
march=athlon flag for the bootstrap. |
9 |
So, I did the bootstrap with march=i686, and right now am |
10 |
re-bootstrapping again with the gcc3.0 and march=athlon, which hopefully |
11 |
now compiles a decent optimized gcc and glibc. And should savely give a |
12 |
full gcc3 system later. |
13 |
|
14 |
Could you confirm that the second bootstrap would be a working interim |
15 |
solution till a gentoo 1.1 (which, to my suprise seems to be |
16 |
downloadable from the gentoo ftp site. Anyone from IRC know what it |
17 |
does?) is released? |
18 |
|
19 |
Greetings, |
20 |
Christian |
21 |
|
22 |
Preston A. Elder wrote: |
23 |
> I'm sure it does ... |
24 |
> |
25 |
> But unless I'm missing something here, changing the profile does NOTHING |
26 |
> to change the utilities (read: tar, bzip2, cp, mv, ls, etc) that are |
27 |
> installed WITH the system. |
28 |
> |
29 |
> Read my email again carefully. I manually made my own |
30 |
> 'default-1.0-gcc3' profile by changing the packages file to use gcc3 |
31 |
> instead of 2.95 and then bootstrapped with it -- and it worked fine |
32 |
> right up until it installed glibc. |
33 |
> |
34 |
> Just incase your not a coder. GLIBC supplies both C and C++ libraries |
35 |
> and symbols for other programs to use. All C++ symbols are 'mangled', |
36 |
> which is a method the compiler uses to differentiate different functions |
37 |
> with the same name but different types (read up on C++ function |
38 |
> overloading and name mangling). |
39 |
> |
40 |
> 3.0 changed the mangling scheme used to mangle C++ names from what was |
41 |
> used with 2.x -- which means, quite simply, if you have an application |
42 |
> thats been compiled against libraries built with gcc 2.x, and then you |
43 |
> compile the libraries with 3.x, the application will cease to work, |
44 |
> because it will not be able to find the symbols it needs to run. |
45 |
> Usually, this will result in a core dump. This only affects programs |
46 |
> written in C++. |
47 |
> |
48 |
> This is exactly what happens with utilities such as tar, which is |
49 |
> written in C++ (which surprised me). Which is why, your |
50 |
> default-1.0-gcc3 profile will *NOT* enable someone to bootstrap with gcc |
51 |
> 3.0, unless you happen to have a stage1 ISO that has statically linked |
52 |
> binaries in it (theoretically, if you have statically linked binaries on |
53 |
> the whole system, you dont even NEED a /lib or /usr/lib directory, |
54 |
> because its all statically linked). |
55 |
> |
56 |
> This was the point I was trying to make. Dont get me wrong, I'm glad |
57 |
> the gcc3 profile is there, and I'm using it, because I use gcc3 |
58 |
> exclusively -- however gcc3 (for now), is only available as a |
59 |
> POST-bootstrap (ie. stage2) compilation, until we get a 1.0 ISO with |
60 |
> statically linked binaries -- or binaries that are still dynamically |
61 |
> linked, but all compiled with gcc3.0 against a glibc compiled with |
62 |
> gcc3.0. Which brings in the chicken and the egg problem. |
63 |
> |
64 |
> This is also why you will have to lock people into a specific glibc |
65 |
> version in your gcc3 profile (which I've noticed you dont do right |
66 |
> now). Say someone bootstraps as normal, then installs gcc3, then |
67 |
> switches to your gcc3 profile, and continues to build the system. If, |
68 |
> at some later point, a new revision or version of glibc comes out, and |
69 |
> is put into the portage tree, and the user then does a world upgrade, |
70 |
> they will attempt to re-compile glibc. It will compile, but as soon as |
71 |
> it installs, a good proportion of the rest of their system will stop |
72 |
> working for exactly the reason I described. I've manually locked my |
73 |
> glibc version because of this fact, because I know I cant re-compile it |
74 |
> with gcc3 without breaking my system. |
75 |
> |
76 |
> If I get time, I'll sit down and think about how to actually create a |
77 |
> stage1 (the thing you tar -xvbjf onto your hard disk) system that is |
78 |
> totally gcc3 based, or see if I can create a stage1 with all statically |
79 |
> linked binaries in it. For now, thats not high on my priority list. |