1 |
On 8/23/06, Alan Mckinnon <alan@××××××××××××××××.za> wrote: |
2 |
> Can you be absolutely certain I'm wrong? Can you absolutely guarantee |
3 |
> that a recompile with a different config MUST be treated differently to |
4 |
> an upgrade? |
5 |
|
6 |
We are still talking about CFLAGS here, right? Then ok, no, it is not |
7 |
_necessary_ to treat this differently than an upgrade in gcc versions. |
8 |
One can happily run "emerge -e system; emerge -e world" and get to |
9 |
the same result. But that doesn't change the fact that the emerge -e |
10 |
system step is redundant _in this case_. |
11 |
|
12 |
Why am I sure? Because many ebuilds in the tree already replace -O3 |
13 |
or -Os with -O2, or add/remove -fsome-flag based on useflags and what |
14 |
is known to break (or fix) something. So on any Gentoo system, you |
15 |
are practically guaranteed to have some binaries that are built with |
16 |
different flags than the libraries they link against, and they all |
17 |
play nicely together. It is part of the standard C/C++ ABI that gcc |
18 |
defines, and compiler flags must not have any effect on that. |
19 |
|
20 |
> As I see it the only difference I can count on is that the first just |
21 |
> happens to not involve a change in version number. |
22 |
|
23 |
No change in version number means no change in ABI. |
24 |
|
25 |
> The only way you could guarantee that is if the gcc sources ignore |
26 |
> CFLAGS and other settings when compiling gcc in an effort to build a |
27 |
|
28 |
Gcc is (almost) always built with -O2 on Gentoo, but it does not |
29 |
matter anyway. The CFLAGS that gcc is built with does not effect the |
30 |
binaries it generates...only the code and the flags passed to gcc |
31 |
during the compilation effect this. If your model were correct, you |
32 |
would need a gcc built with -Os for using -Os, a gcc built with "-Os |
33 |
-fweb" for building with "-Os -fweb", "-O3" for building with -O3, |
34 |
"-O3 -mmx" for ... and so on. |
35 |
|
36 |
Think about this for a second. What you are claiming here is that the |
37 |
output of this bash script can depend upon what CFLAGS bash was built |
38 |
with: |
39 |
|
40 |
#!/bin/bash |
41 |
echo -e "\x48\x65\x6c\x6c\x6f\x20\x57\x6f\x72\x6c\x64\x21" |
42 |
|
43 |
Admittedly a compiler is many orders of magnitude more complex than |
44 |
this, but functionally the same. Only the code and the options passed |
45 |
to the compiler can effect its output. Or to put another way, one |
46 |
could write a C compiler in java, C#, python, or even shell script |
47 |
that would support the exact same flags as gcc and generate the exact |
48 |
same code. They would almost certainly be much, much slower, but the |
49 |
output would be the same. It is identical in concept to changing the |
50 |
flags that _gcc_ is built with...the gcc program itself changes |
51 |
(hopefully gets faster), but the output remains the same. |
52 |
|
53 |
-Richard |
54 |
-- |
55 |
gentoo-user@g.o mailing list |