1 |
On Thu, Dec 10, 2020 at 4:18 PM n952162 <n952162@×××.de> wrote: |
2 |
> |
3 |
> On 12/10/20 7:18 PM, Rich Freeman wrote: |
4 |
> > On Thu, Dec 10, 2020 at 10:23 AM n952162 <n952162@×××.de> wrote: |
5 |
> >> I need a new mainboard. What will happen if I boot my existing system |
6 |
> >> on it? |
7 |
> > Is the CPU going to be the same? The responses already cover the |
8 |
> > mainboard itself well. If the CPU could change then you need to check |
9 |
> > your -march in CFLAGS for compatibility (if you set it) and |
10 |
> > potentially rebuild anything you don't want to break. |
11 |
> > |
12 |
> |
13 |
> How would I do that? Would I have to set up a cross-compiler toolchain? |
14 |
|
15 |
Nope, just remove -march from your CFLAGS (maybe change it to -mtune) |
16 |
and emerge -e @world (or @system if you don't care if non-system |
17 |
packages are broken on the new system). |
18 |
|
19 |
It is only necessary if you're switching CPUs. If you're using -march |
20 |
then your binaries are not guaranteed to run on ANY CPU other than the |
21 |
one specified, and you'd be surprised how non-backwards-compatible |
22 |
CPUs can be. With gcc the -march option tells the compiler that it |
23 |
can use any instruction it can to optimize things, including ones that |
24 |
are very uncommon on other CPU models. -mtune makes optimizations but |
25 |
the code will run on any CPU for that architecture. |
26 |
|
27 |
You can try to find a least-common-denominator CPU but it usually |
28 |
isn't worth the hassle. |
29 |
|
30 |
-- |
31 |
Rich |