1 |
I'm sure it does ... |
2 |
|
3 |
But unless I'm missing something here, changing the profile does NOTHING |
4 |
to change the utilities (read: tar, bzip2, cp, mv, ls, etc) that are |
5 |
installed WITH the system. |
6 |
|
7 |
Read my email again carefully. I manually made my own |
8 |
'default-1.0-gcc3' profile by changing the packages file to use gcc3 |
9 |
instead of 2.95 and then bootstrapped with it -- and it worked fine |
10 |
right up until it installed glibc. |
11 |
|
12 |
Just incase your not a coder. GLIBC supplies both C and C++ libraries |
13 |
and symbols for other programs to use. All C++ symbols are 'mangled', |
14 |
which is a method the compiler uses to differentiate different functions |
15 |
with the same name but different types (read up on C++ function |
16 |
overloading and name mangling). |
17 |
|
18 |
3.0 changed the mangling scheme used to mangle C++ names from what was |
19 |
used with 2.x -- which means, quite simply, if you have an application |
20 |
thats been compiled against libraries built with gcc 2.x, and then you |
21 |
compile the libraries with 3.x, the application will cease to work, |
22 |
because it will not be able to find the symbols it needs to run. |
23 |
Usually, this will result in a core dump. This only affects programs |
24 |
written in C++. |
25 |
|
26 |
This is exactly what happens with utilities such as tar, which is |
27 |
written in C++ (which surprised me). Which is why, your |
28 |
default-1.0-gcc3 profile will *NOT* enable someone to bootstrap with gcc |
29 |
3.0, unless you happen to have a stage1 ISO that has statically linked |
30 |
binaries in it (theoretically, if you have statically linked binaries on |
31 |
the whole system, you dont even NEED a /lib or /usr/lib directory, |
32 |
because its all statically linked). |
33 |
|
34 |
This was the point I was trying to make. Dont get me wrong, I'm glad |
35 |
the gcc3 profile is there, and I'm using it, because I use gcc3 |
36 |
exclusively -- however gcc3 (for now), is only available as a |
37 |
POST-bootstrap (ie. stage2) compilation, until we get a 1.0 ISO with |
38 |
statically linked binaries -- or binaries that are still dynamically |
39 |
linked, but all compiled with gcc3.0 against a glibc compiled with |
40 |
gcc3.0. Which brings in the chicken and the egg problem. |
41 |
|
42 |
This is also why you will have to lock people into a specific glibc |
43 |
version in your gcc3 profile (which I've noticed you dont do right |
44 |
now). Say someone bootstraps as normal, then installs gcc3, then |
45 |
switches to your gcc3 profile, and continues to build the system. If, |
46 |
at some later point, a new revision or version of glibc comes out, and |
47 |
is put into the portage tree, and the user then does a world upgrade, |
48 |
they will attempt to re-compile glibc. It will compile, but as soon as |
49 |
it installs, a good proportion of the rest of their system will stop |
50 |
working for exactly the reason I described. I've manually locked my |
51 |
glibc version because of this fact, because I know I cant re-compile it |
52 |
with gcc3 without breaking my system. |
53 |
|
54 |
If I get time, I'll sit down and think about how to actually create a |
55 |
stage1 (the thing you tar -xvbjf onto your hard disk) system that is |
56 |
totally gcc3 based, or see if I can create a stage1 with all statically |
57 |
linked binaries in it. For now, thats not high on my priority list. |
58 |
|
59 |
On Sun, 2002-04-07 at 06:14, Geert Bevin wrote: |
60 |
> Changing the profile in /etc/make.profile to default-1.0-gcc3 should |
61 |
> make you bootstrap against gcc3 instead. |
62 |
> |
63 |
> On Sun, 2002-04-07 at 05:29, Preston A. Elder wrote: |
64 |
> > Personally, I'd be very interested to know how you did this 'from |
65 |
> > scratch'. |
66 |
> > |
67 |
> > I myself have done this from the post-bootstrap (but pre emerge system) |
68 |
> > stage on, but I cant bootstrap with 3.0.x, why? |
69 |
> > |
70 |
> > Well, the image the ISO installs has many applications on it, not linked |
71 |
> > statically (eg. tar, etc) -- compiling gcc3.0.4 works fine, but as soon |
72 |
> > as it then compiles glibc 2.2.5 and installs it, nothing else works. |
73 |
> > |
74 |
> > The utilities on the install image look for glibc 2.2.5 compiled with |
75 |
> > gcc 2.95.x. So until there is an install image that has statically |
76 |
> > linked binaries on it, I dont see how a bootstrap can be achieved using |
77 |
> > 3.0.x compilers. |
78 |
> > |
79 |
> > I too, however, have installed a 3.0.x based system. I did the |
80 |
> > bootstrap on 2.95.3, then first thing after bootstrap, I merged gcc |
81 |
> > 3.0.4, and then did my emerge system. As Geert said, a few problems |
82 |
> > along the way, but not many. I too made patches for all the problems I |
83 |
> > found, I submitted them to Geert. The patches I made are ALL backward |
84 |
> > compatable to 2.95.3 (I believe, I've not tested this). But then, I |
85 |
> > could also have compiled a different package set than he did. |
86 |
> > |
87 |
> > |
88 |
> > On Sat, 2002-04-06 at 07:01, Geert Bevin wrote: |
89 |
> > > Hi all, |
90 |
> > > |
91 |
> > > I finally installed 1.0 from scratch and decided to try it out with gcc |
92 |
> > > 3.0.4 instead of 2.95.3. Along the way I encountered some problems, but |
93 |
> > > surprisingly little. I've fixed everything that needed fixing and sadly |
94 |
> > > some packages are backwards incompatible. For that reason and for the |
95 |
> > > ease of maintenance I've created a dedicated gcc 3 profile. |
96 |
> > > |
97 |
> > > So, for those that want to try this out, just link the default-1.0-gcc3 |
98 |
> > > profile instead of default-1.0 to /etc/make.profile. Note that this will |
99 |
> > > only work for installations from scratch and not for updates since |
100 |
> > > applications that link against libstdc++ v2 require the libraries of gcc |
101 |
> > > v2 and not gcc v3. |
102 |
> > > |
103 |
> > > There are still some packages that don't compile such as galeon and |
104 |
> > > openjade, but these will be fixed in a matter of time since I need them |
105 |
> > > ;-) Feel free to submit fixes too. |
106 |
> > > |
107 |
> > > Best regards, |
108 |
> > > |
109 |
> > > Geert Bevin |
110 |
> > > -- |
111 |
> > > Geert Bevin Uwyn |
112 |
> > > "Use what you need" Lambermontlaan 148 |
113 |
> > > http://www.uwyn.com 1030 Brussels |
114 |
> > > gbevin@××××.com Tel & Fax +32 2 245 41 06 |
115 |
> > > |
116 |
> > > _______________________________________________ |
117 |
> > > gentoo-dev mailing list |
118 |
> > > gentoo-dev@g.o |
119 |
> > > http://lists.gentoo.org/mailman/listinfo/gentoo-dev |
120 |
> > |
121 |
> > Thanks, |
122 |
> > |
123 |
> > -- |
124 |
> > PreZ |
125 |
> > Systems Administrator |
126 |
> > GOTH.NET |
127 |
> > |
128 |
> > Goth Code '98: tSKeba5qaSabsaaaGbaa75KAASWGuajmsvbieqcL4BaaLb3F4 |
129 |
> > nId5mefqmDjmmgm#haxthgzpj4GiysNkycSRGHabiabOkauNSW |
130 |
> > |
131 |
> > GOTH.NET - http://www.goth.net |
132 |
> > Free online resource for the gothic community. |
133 |
> -- |
134 |
> Geert Bevin Uwyn |
135 |
> "Use what you need" Lambermontlaan 148 |
136 |
> http://www.uwyn.com 1030 Brussels |
137 |
> gbevin@××××.com Tel & Fax +32 2 245 41 06 |
138 |
> |
139 |
> _______________________________________________ |
140 |
> gentoo-dev mailing list |
141 |
> gentoo-dev@g.o |
142 |
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev |
143 |
-- |
144 |
PreZ |
145 |
Systems Administrator |
146 |
GOTH.NET |
147 |
|
148 |
Goth Code '98: tSKeba5qaSabsaaaGbaa75KAASWGuajmsvbieqcL4BaaLb3F4 |
149 |
nId5mefqmDjmmgm#haxthgzpj4GiysNkycSRGHabiabOkauNSW |
150 |
|
151 |
GOTH.NET - http://www.goth.net |
152 |
Free online resource for the gothic community. |