# Laptop dying need to rebuild packages for another architectu

## LIsLinuxIsSogood

As the post says, my laptop is on its way out.  At least for the time being, until I can get it fixed.  Help is much appreciated. Thanks

Having recently rebuilt a bunch of packages for the specific architecture (i3 processor), I am now moving it over to a desktop where I can't seem to boot or chroot.  The desktop has a Pentium G2120 chip in it.  I think it is clearly a result of the recent rebuilding of packages with the architecture issue.  Now I'm just wondering in order to prepare the disk to be booted from that other machine, what is the minimum that I need to do.  Or in other words, is there some quicker way than with emerge -e @world it wants to build some 900+ packages...that could take too long!  

The emerge --info while booted on the laptop is:

https://paste.pound-python.org/show/9GJWXSJQyQDtHtwd2Ne1/

But I do have a point of reference here to go by if it is helpful....a second installation already on the desktop where I am going to need to boot this disk

https://paste.pound-python.org/show/FLHukqQZFRxbrtPqpdRq/

EDIT: NOTE I ALREADY CHANGED THE CFLAGS IN THE MAKE.CONF FILE AND AM ONLY WAITING TO RUN THE APPROPRIATE PACKAGE REBUILD THROUGH PORTAGE, HENCE THE FACT THAT SOMETHING MIGHT LOOK LIKE IT IS "UP WITH" THE FIRST OF THE TWO LINKS ABOVE

(i know it should not need to match identically but whatever suggestions other than rebuilding the entire system that could help me to get there sooner would be great!)

----------

## ct85711

Ok, assuming you are staying as 64bit system or as a straight 32bit system; you should be able to get by just setting --march=generic; which will make your system generic in that it's not restricted on cpu instruction.  Beyond that, the main parts you'd want to do, is recompile gcc, glibc, then do @system, and possibly the kernel (though you'd probably have to recompile that anyways, so could hold off on it).  This will make your base system generic, so you can boot from a boot cd, mount into the linux partition, configure a kernel for the new machine and start rebuilding your machine.  You won't necessarily have X11 going, so you will be stuck using straight command line; but after you have a working kernel and loaded the linux partition from that you can then do emerge -e world (after updating your march again for the correct system; and be up once again).

You may look through this forum thread, as some of it is still useful even though you may not be using getting a Ryzen (I am assuming you are not, if so even better).  Either way, it has some advice on getting your system to be to the point of being most compatible to all cpu's to minimize the issue when transitioning.

https://forums.gentoo.org/viewtopic-p-8075482.html

If you are wanting to transition form 32bit to 64bit, you are better off just coping your world file and start from over...

----------

## LIsLinuxIsSogood

K, this is no problem.  Thanks

Would you recommend for the first few steps using a less integrated way such as ebuild to interface with those, or can emerge still handle most of the lifting when it comes to rebuilds?

----------

## LIsLinuxIsSogood

How do you suggest I recompile them, do I need to remove them or else tell portage to look elsewhere while I sneakily replace the files?

Help it currently doesn't want to do another action if I just say -new use or -changed-use?

----------

## ct85711

you should be able to just modify your make.conf to use the new cflags (just use the bare basics for flags, you can later go update them on the new system).

After that, portage will be able to reinstall the packages it's self (it will use the updated cflags you set in your make.conf), just remember to use -1/--oneshot when recompiling the packages.

Note:  DO NOT REMOVE THOSE PACKAGES!!!  You WILL break your system by doing so, let portage do the work.

----------

## LIsLinuxIsSogood

Well I just ran into my first problem after installing gcc and glibc successfully. 

Package: app-arch/gzip-1.8::gentoo

https://paste.pound-python.org/show/xSwXcqTSHjXNDpW5Q8UT/

Packages that were installed with -march=generic already

https://paste.pound-python.org/show/dXkptP61ic586B0VHNbp/

https://paste.pound-python.org/show/kaixuAwqgRSyhnz6kdQu/

What is it related to anything?  Could I be missing a -mtune=switch perhaps some of the current output I am getting from portage looks like it is probably causing issues to have the generic setting for -march without -mtune set properly...

----------

## LIsLinuxIsSogood

Not really sure what's wrong, but here it goes...it would appear from this configuration log that it could be important

```
This file contains any messages produced by compilers while

running configure, to aid debugging if configure makes a mistake.

It was created by python-exec configure 2.4.4, which was

generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --libdir=/usr/lib64 --with-python-impls=jython2.7 pypy pypy3 python2.7 python3.4 python3.5 python3.6

## --------- ##

## Platform. ##

## --------- ##

hostname = sysresccd

uname -m = x86_64

uname -r = 4.9.40-std503-amd64

uname -s = Linux

uname -v = #2 SMP Fri Jul 28 07:04:43 UTC 2017

/usr/bin/uname -p = Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz

/bin/uname -X     = unknown

/bin/arch              = unknown

/usr/bin/arch -k       = unknown

/usr/convex/getsysinfo = unknown

/usr/bin/hostinfo      = unknown

/bin/machine           = unknown

/usr/bin/oslevel       = unknown

/bin/universe          = unknown

PATH: /usr/lib64/distcc/bin

PATH: /var/tmp/portage/._portage_reinstall_.0x6sgwbf/bin/ebuild-helpers/xattr

PATH: /usr/lib/portage/python3.4/ebuild-helpers/xattr

PATH: /var/tmp/portage/._portage_reinstall_.0x6sgwbf/bin/ebuild-helpers

PATH: /usr/lib/portage/python3.4/ebuild-helpers

PATH: /usr/local/sbin

PATH: /usr/local/bin

PATH: /usr/sbin

PATH: /usr/bin

PATH: /sbin

PATH: /bin

PATH: /opt/bin

PATH: /usr/i486-pc-linux-gnu/gcc-bin/5.4.0

## ----------- ##

## Core tests. ##

## ----------- ##

configure:2271: checking for a BSD-compatible install

configure:2339: result: /var/tmp/portage/._portage_reinstall_.0x6sgwbf/bin/ebuild-helpers/xattr/install -c

configure:2350: checking whether build environment is sane

configure:2405: result: yes

configure:2556: checking for a thread-safe mkdir -p

configure:2595: result: /bin/mkdir -p

configure:2602: checking for gawk

configure:2618: found /usr/bin/gawk

configure:2629: result: gawk

configure:2640: checking whether make sets $(MAKE)

configure:2662: result: yes

configure:2691: checking whether make supports nested variables

configure:2708: result: yes

configure:2846: checking whether make supports nested variables

configure:2863: result: yes

configure:2883: checking for x86_64-pc-linux-gnu-gcc

configure:2899: found /usr/lib64/distcc/bin/x86_64-pc-linux-gnu-gcc

configure:2910: result: x86_64-pc-linux-gnu-gcc

configure:3179: checking for C compiler version

configure:3188: x86_64-pc-linux-gnu-gcc --version >&5

x86_64-pc-linux-gnu-gcc (Gentoo 5.4.0-r3 p1.4, pie-0.6.5) 5.4.0

Copyright (C) 2015 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3199: $? = 0

configure:3188: x86_64-pc-linux-gnu-gcc -v >&5

Using built-in specs.

COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0/x86_64-pc-linux-gnu-gcc

COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/lto-wrapper

Target: x86_64-pc-linux-gnu

Configured with: /var/tmp/portage/sys-devel/gcc-5.4.0-r3/work/gcc-5.4.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.4.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.4.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 5.4.0-r3 p1.4, pie-0.6.5' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer

Thread model: posix

gcc version 5.4.0 (Gentoo 5.4.0-r3 p1.4, pie-0.6.5) 

configure:3199: $? = 0

configure:3188: x86_64-pc-linux-gnu-gcc -V >&5

x86_64-pc-linux-gnu-gcc: error: unrecognized command line option '-V'

x86_64-pc-linux-gnu-gcc: fatal error: no input files

compilation terminated.

distcc[32029] ERROR: compile (null) on localhost failed

configure:3199: $? = 1

configure:3188: x86_64-pc-linux-gnu-gcc -qversion >&5

x86_64-pc-linux-gnu-gcc: error: unrecognized command line option '-qversion'

x86_64-pc-linux-gnu-gcc: fatal error: no input files

compilation terminated.

distcc[32035] ERROR: compile (null) on localhost failed

configure:3199: $? = 1

configure:3219: checking whether the C compiler works

configure:3241: x86_64-pc-linux-gnu-gcc -march=generic -O2 -pipe  -Wl,-O1 -Wl,--as-needed conftest.c  >&5

conftest.c:1:0: error: generic CPU can be used only for -mtune= switch

 /* confdefs.h */

 ^

distcc[32046] ERROR: compile conftest.c on localhost failed

configure:3245: $? = 1

configure:3283: result: no

configure: failed program was:

| /* confdefs.h */

| #define PACKAGE_NAME "python-exec"

| #define PACKAGE_TARNAME "python-exec"

| #define PACKAGE_VERSION "2.4.4"

| #define PACKAGE_STRING "python-exec 2.4.4"

| #define PACKAGE_BUGREPORT ""

| #define PACKAGE_URL ""

| #define PYTHON_IMPLS { "python3.6", IMPL_DEFAULT }, { "python3.5", IMPL_DEFAULT }, { "python3.4", IMPL_DEFAULT }, { "python2.7", IMPL_DEFAULT }, { "pypy3", IMPL_DEFAULT }, { "pypy", IMPL_DEFAULT }, { "jython2.7", IMPL_DEFAULT }, { 0, 0 }

| #define MAX_EPYTHON_LEN 9

| #define PACKAGE "python-exec"

| #define VERSION "2.4.4"

| /* end confdefs.h.  */

| 

| int

| main ()

| {

| 

|   ;

|   return 0;

| }

configure:3288: error: in `/var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4':

configure:3290: error: C compiler cannot create executables

See `config.log' for more details

## ---------------- ##

## Cache variables. ##

## ---------------- ##

ac_cv_env_CC_set=

ac_cv_env_CC_value=

ac_cv_env_CFLAGS_set=set

ac_cv_env_CFLAGS_value='-march=generic -O2 -pipe'

ac_cv_env_CPPFLAGS_set=

ac_cv_env_CPPFLAGS_value=

ac_cv_env_CPP_set=

ac_cv_env_CPP_value=

ac_cv_env_LDFLAGS_set=set

ac_cv_env_LDFLAGS_value='-Wl,-O1 -Wl,--as-needed'

ac_cv_env_LIBS_set=

ac_cv_env_LIBS_value=

ac_cv_env_build_alias_set=set

ac_cv_env_build_alias_value=x86_64-pc-linux-gnu

ac_cv_env_host_alias_set=set

ac_cv_env_host_alias_value=x86_64-pc-linux-gnu

ac_cv_env_target_alias_set=

ac_cv_env_target_alias_value=

ac_cv_path_install='/var/tmp/portage/._portage_reinstall_.0x6sgwbf/bin/ebuild-helpers/xattr/install -c'

ac_cv_path_mkdir=/bin/mkdir

ac_cv_prog_AWK=gawk

ac_cv_prog_CC=x86_64-pc-linux-gnu-gcc

ac_cv_prog_make_make_set=yes

am_cv_make_support_nested_variables=yes

## ----------------- ##

## Output variables. ##

## ----------------- ##

ACLOCAL='${SHELL} /var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4/build-aux/missing aclocal-1.15'

AMDEPBACKSLASH=''

AMDEP_FALSE=''

AMDEP_TRUE=''

AMTAR='$${TAR-tar}'

AM_BACKSLASH='\'

AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)'

AM_DEFAULT_VERBOSITY='1'

AM_V='$(V)'

AUTOCONF='${SHELL} /var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4/build-aux/missing autoconf'

AUTOHEADER='${SHELL} /var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4/build-aux/missing autoheader'

AUTOMAKE='${SHELL} /var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4/build-aux/missing automake-1.15'

AWK='gawk'

CC='x86_64-pc-linux-gnu-gcc'

CCDEPMODE=''

CFLAGS='-march=generic -O2 -pipe'

CPP=''

CPPFLAGS=''

CYGPATH_W='echo'

DEFS=''

DEPDIR=''

ECHO_C=''

ECHO_N='-n'

ECHO_T=''

EGREP=''

EXEEXT=''

GREP=''

HAVE_READLINK_FALSE=''

HAVE_READLINK_TRUE=''

INSTALL_DATA='${INSTALL} -m 644'

INSTALL_PROGRAM='${INSTALL}'

INSTALL_SCRIPT='${INSTALL}'

INSTALL_STRIP_PROGRAM='$(install_sh) -c -s'

LDFLAGS='-Wl,-O1 -Wl,--as-needed'

LIBOBJS=''

LIBS=''

LTLIBOBJS=''

MAKEINFO='${SHELL} /var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4/build-aux/missing makeinfo'

MKDIR_P='/bin/mkdir -p'

OBJEXT=''

PACKAGE='python-exec'

PACKAGE_BUGREPORT=''

PACKAGE_NAME='python-exec'

PACKAGE_STRING='python-exec 2.4.4'

PACKAGE_TARNAME='python-exec'

PACKAGE_URL=''

PACKAGE_VERSION='2.4.4'

PATH_SEPARATOR=':'

PYTHON_IMPLS='jython2.7 pypy pypy3 python2.7 python3.4 python3.5 python3.6'

SED=''

SET_MAKE=''

SHELL='/bin/sh'

STRIP=''

VERSION='2.4.4'

ac_ct_CC=''

am__EXEEXT_FALSE=''

am__EXEEXT_TRUE=''

am__fastdepCC_FALSE=''

am__fastdepCC_TRUE=''

am__include=''

am__isrc=''

am__leading_dot='.'

am__nodep=''

am__quote=''

am__tar='$${TAR-tar} chof - "$$tardir"'

am__untar='$${TAR-tar} xf -'

bindir='${exec_prefix}/bin'

build_alias='x86_64-pc-linux-gnu'

datadir='/usr/share'

datarootdir='${prefix}/share'

docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'

dvidir='${docdir}'

exec_prefix='NONE'

host_alias='x86_64-pc-linux-gnu'

htmldir='${docdir}'

includedir='${prefix}/include'

infodir='/usr/share/info'

install_sh='${SHELL} /var/tmp/portage/dev-lang/python-exec-2.4.4/work/python-exec-2.4.4/build-aux/install-sh'

libdir='/usr/lib64'

libexecdir='${exec_prefix}/libexec'

localedir='${datarootdir}/locale'

localstatedir='/var/lib'

mandir='/usr/share/man'

mkdir_p='$(MKDIR_P)'

oldincludedir='/usr/include'

pdfdir='${docdir}'

prefix='/usr'

program_transform_name='s,x,x,'

psdir='${docdir}'

sbindir='${exec_prefix}/sbin'

scriptrootdir='${exec_prefix}/lib/python-exec'

sharedstatedir='${prefix}/com'

sysconfdir='/etc'

target_alias=''

## ----------- ##

## confdefs.h. ##

## ----------- ##

/* confdefs.h */

#define PACKAGE_NAME "python-exec"

#define PACKAGE_TARNAME "python-exec"

#define PACKAGE_VERSION "2.4.4"

#define PACKAGE_STRING "python-exec 2.4.4"

#define PACKAGE_BUGREPORT ""

#define PACKAGE_URL ""

#define PYTHON_IMPLS { "python3.6", IMPL_DEFAULT }, { "python3.5", IMPL_DEFAULT }, { "python3.4", IMPL_DEFAULT }, { "python2.7", IMPL_DEFAULT }, { "pypy3", IMPL_DEFAULT }, { "pypy", IMPL_DEFAULT }, { "jython2.7", IMPL_DEFAULT }, { 0, 0 }

#define MAX_EPYTHON_LEN 9

#define PACKAGE "python-exec"

#define VERSION "2.4.4"

configure: exit 77

```

[Moderator edit: changed [quote] tags to [code] tags to preserve output layout. -Hu]

----------

## ct85711

 *Quote:*   

> Could I be missing a -mtune=switch perhaps some of the current output I am getting from portage looks like it is probably causing issues to have the generic setting for -march without -mtune set properly...

 

From what it appears, and from my research, it does seem this is the case.  This is more of a difficult case in that gcc's documentation does not include all of the options you can use.  From what it looks like, you will need to either add

-mtune=x86_64 or change -march=generic to -march=x86_64.

----------

## LIsLinuxIsSogood

Does this cross compiling for different archictures present some limits with Portage?  I had to undo everything so it is back to the way it was before I made any attempt to change the software for the Pentium chip on my desktop to be able to chroot/boot into it. 

I do appreciate the help thus far, and will attempt to do some further research, but from what I was able to gather based on some of the research I did that -mtune is not really what I need, because it does not actually change the way that the architecture code is processed.  But moving from i3 to pentium, means that I think you are right to say that -march=x86_64 should work for the cxx flag.

But what about other packages that were going to be built with multilib support, should those packages still work the same in terms of builds?

----------

## NeddySeagoon

LIsLinuxIsSogood,

This isn't cross compiling. Its changing the way code is tuned to the CPU, so you don't get illegal instruction errors when its in its new home.

Cross compiling is building for say a Raspberry Pi (arm or arm64) on an amd64 or i686 system.

You need to fix your CFLAGS and CPU_FLAGS_X86= to reflect the new CPU. 

-mtune="generic" with -mcpu and -march both unset is as generic as you get on amd64.  That will produce run anywhere (amd64) code.

----------

## ct85711

As Neddy mentioned, this is only so that you can move your linux system to another machine and it will work there (exception of maybe the kernel not having the new hardware support).

This is usually only needed when you are switching cpu bands, like moving from a intel to an amd CPU.  The reason is that amd and intel don't support all of the same instructions.  Quite often, moving from a older intel  to an new intel cpu, isn't as much of an issue as the new intel often supports all or most of the old intel cpu's instructions.  Once your system is fully compiled to be generic, you will be close to what other distro's are set at (they are compiled for as generic as possible), so the same software can be using on as wide of range of computers with only supplying 1 binary package.  This is the same of how windows works, in that there is only 2 copies of the same one; one for 32bit and one for 64bit with no optimizations...

----------

## LIsLinuxIsSogood

I need help again, still recompiling gcc again for like the 4th time.

According to safe CFLAGS article on wiki,  the settings for a Pentium are:

Pentium

vendor_id : GenuineIntel

cpu family : 6

model : 58

model name : Intel(R) Pentium(R) CPU G2020 @ 2.90GHz

FILE /etc/portage/make.conf

CHOST="x86_64-pc-linux-gnu"

CFLAGS="-march=ivybridge -mno-avx -mno-aes -mno-rdrnd -O2 -pipe"

CXXFLAGS="${CFLAGS}"

I don't see how come it should be so difficult to build packages for the two Intel chips then again I am not 100% clear on what chroot actually does other than to change the root folder and call on the shell again?!

I am however afraid that the difference in the models of CPUs between the two machines is somehow in need of the more extreme measure perhaps reinstalling, IDK.

Does the system set, itself even seem necessary just to chroot, shouldn't there be a even more minimal set of packages, that could be applied for the new chrooted environment?

I do not want to reinstall if at all possible.Last edited by LIsLinuxIsSogood on Tue Sep 12, 2017 2:57 am; edited 1 time in total

----------

## LIsLinuxIsSogood

At least according to the safe CFLAGS article on the wiki, these are the settings that are listed for a Pentium 

Pentium

vendor_id	: GenuineIntel

cpu family	: 6

model		: 58

model name	: Intel(R) Pentium(R) CPU G2020 @ 2.90GHz

FILE /etc/portage/make.conf

CHOST="x86_64-pc-linux-gnu"

CFLAGS="-march=ivybridge -mno-avx -mno-aes -mno-rdrnd -O2 -pipe"

CXXFLAGS="${CFLAGS}"

Now, I tried that and as discussed the problem with this was somehow unable to continue with the compilation on the current system, so it was no good,  If I alternatively try to recompile all packages with the -march=x86_64 is that going to be my best bet...so far I've tried everything but that in the hopes of figuring out how the -mtune setting might work, but it has not.  I am afraid that the difference in the models of CPUs between the two machines is somehow in need of the more extreme measure.

----------

## ct85711

Ok, first off; do you know if the new cpu is going to be an intel or not?  If you what approximately like what the new cpu is, we can figure out what it supports; then we compare between the 2.  If you are staying within the same brand, you may not need to change your cflags at all; as the instructions would already be compatible on the new cpu.

Since we don't know what the new cpu is, we are going by the safest assumption that it is not compatible with the old cpu.  That means getting the system as generic as possible.

----------

## LIsLinuxIsSogood

I agree that was a bit unclear before so here it is... The laptop that I am in need of replacing/repairing  is for now on its way out...and what that means is for the time being I will be downgrading CPU (to the desktop Pentium IV?... G2120 , while I attempt to still remain working from within the OS on the hard drive. Since that G2120 chip is an older chip than my laptop, I will eventually like to get a new laptop with a newer (more advanced chip in it).  until then, it would appear that my problem could be due to the downgrading of sorts.

From your earlier posts....

 *Quote:*   

>  Quite often, moving from a older intel to an new intel cpu, isn't as much of an issue as the new intel often supports all or most of the old intel cpu's instructions.

 

What seems to be happening is that I cannot get through the set of system packages without a ton of errors, no matter whether or not gcc has been previously compiled, it continuiously is failing in the following way:

```
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc

checking whether the C compiler works... no

configure: error: in `/var/tmp/portage/app-shells/bash-4.3_p48-r1/work/bash-4.3':

configure: error: C compiler cannot create executables

See `config.log' for more details

```

Maybe something in here makes more sense now that I mentioned it is going backwards in terms of the CPU direction.

EDIT: From another post https://forums.gentoo.org/viewtopic-t-941720-start-0.html there is mention of other possible libraries that support the chroot.  Is there a comprehensive list of these libraries somewhere?

----------

## NeddySeagoon

LIsLinuxIsSogood,

```
configure: error: C compiler cannot create executables 
```

Usually means that there in a problem with your CFLAGS.  Often something that gcc does not understand.

Exactly what will be in 

```
See `config.log' for more details 
```

which will be close to the end of /var/tmp/portage/app-shells/bash-4.3_p48-r1/work/bash-4.3

Mixing up -02 and -O2 is popular.

You don't need a great deal to be able to chroot, certainly not all of @system but lens fix gcc first.

----------

## LIsLinuxIsSogood

Wouldn't gcc need to necessarily be the last one to be built, otherwise how will it get used if it is compiled for use with a different architecture!?

----------

## LIsLinuxIsSogood

https://paste.pound-python.org/show/LAvwvnlsmQpzawpiI6a5/

I would be much obliged, if you were to take a look at the output from emerge --info and let me know if the CFLAG and CXXFLAG settings are right.

----------

## NeddySeagoon

LIsLinuxIsSogood,

```
CFLAGS="-march=x86_64 -O2 -pipe"
```

looks to be illegal.  The gcc man page does not list -march=x86_64.

Use 

```
CFLAGS="-mtune=generic -O2 -pipe"
```

```
           generic

               Produce code optimized for the most common IA32/AMD64/EM64T

               processors.  If you know the CPU on which your code will run,

               then you should use the corresponding -mtune or -march option

               instead of -mtune=generic.  But, if you do not know exactly

               what CPU users of your application will have, then you should

               use this option.
```

Do not give a -march option.

These options tell gcc what system to generate code for.  It its not built that way itself, it does not matter as long is the gcc you have runs on the CPU you need it to.

The rebuilt gcc will run in its new home.

----------

## LIsLinuxIsSogood

So theni would want to use the following

 *Quote:*   

> 
> 
> If you know the CPU on which your code will run, 
> 
>                then you should use the corresponding -mtune or -march option 
> ...

 

With CFLAGS as in this file https://paste.pound-python.org/show/9GJWXSJQyQDtHtwd2Ne1/

I don't recall the result of this trial but is that accurate?

----------

## NeddySeagoon

LIsLinuxIsSogood,

```
CFLAGS="-march=ivybridge -mno -avx -mno-aes -mno-rdrnd -O2 -pipe"
```

That says to emit code for an Ivybridge CPU but do not use avx, aes or rdrnd instruction sets.

There is a typo there too.  -mno -avx should be  -mno-avx (no space).

I can't say if that's right for your CPU or not.

----------

## LIsLinuxIsSogood

Ok let's start a couple steps earlier then.  How do I get gcc working correctly, and what would be the next steps once it works before moving over the hard drive to the older machine?

Update: My latest attempts to recompile the C compiler, plus libraries needed for the system set, which included the packages here

```
playby / # eix -c --system | wgetpaste

```

https://paste.pound-python.org/show/DCREWotYfN4y3xY78Raf/

I'm also going to include the following information for the system that it was built on...

```
playby / # emerge --info | wgetpaste

```

 https://paste.pound-python.org/show/u1gY27lGHN6WqlCNt3Zs/

At least my attempt at doing it this way, I know is possible (or else others on the forum would not be instructing on the proper methods, right?)...however, if I can't succeed with getting it on the next try at the maximum, I am thinking that I will go about it with rebuilding the entier system from a stage3 on the other desktop computer.  Then it will be perhaps less dreadful or perhaps more dreadful aspect of comparing the configurations that are all 1-2 years of working within the OS that I am now without a laptop, but this is seriously giving me some new thoughts as well about how I may better proceed in the future with not taking for granted the aspect of the directory structure of the file system and keep everything as organized as possible for situations like these.

I guess in the mean time since I could probably just transfer everything over from this hard drive to a backup file, and then reuse (this is one of only a couple of drives that I have that I wanted to be putting to use in whatever the machine is I will be using).  For now because of the broken circuitry in my laptop, this disk is already removed so that I could return the laptop to the manufacturer for repair.  In truth, I will probably buy another laptop soon, and 1 thing I have to think about is if it will be a new or old laptop for the final transfer back to a laptop for the working system that I need for everything from work, to learning/researching and fun stuff as well.

Any suggestions about the original post that has to do with making use of the drive in the separate machine (I will be glad to explain again why and also what I've so far built/compiled in terms of system software and peripheral type of software to that).

----------

## NeddySeagoon

LIsLinuxIsSogood,

That looks good so far.

You will also need to rebuild your kernel and boot loader for the correct or generic CPU.  The kernel build system does not use make.conf at all.

Don't forget to reinstall them both too.

When you rebuild your kernel, you need to include hardware support for the motherboard its running on now and the new motherboard, so the same kernel works in both places.

Be careful of the virtuals,

```
[I] virtual/dev-manager (0@09/12/2017): Virtual for the device filesystem manager

[I] virtual/editor (0@09/12/2017): Virtual for editor

[I] virtual/libc (1@09/12/2017): Virtual for the C library

[I] virtual/man (0-r1@09/12/2017): Virtual for man

[I] virtual/modutils (0@09/12/2017): Virtual for utilities to manage Linux kernel modules

[I] virtual/os-headers (0@09/12/2017): Virtual for operating system headers

[I] virtual/package-manager (0@09/12/2017): Virtual for the package manager

[I] virtual/pager (0@09/12/2017): Virtual for command-line pagers

[I] virtual/service-manager (0@09/12/2017): Virtual for various service managers

[I] virtual/shadow (0@09/12/2017): Virtual for user account management utilities

[I] virtual/ssh (0@09/12/2017): Virtual for SSH client and server
```

You need whatever you have installed that satisfies each virtual to be rebuilt too, not just the virtual itself.

Have a look at the end of /var/log/emerge.log to make sure.

----------

## LIsLinuxIsSogood

 *Quote:*   

> When you rebuild your kernel, you need to include hardware support for the motherboard its running on now and the new motherboard, so the same kernel works in both places. 

 

Can i assume from this the approach that is more standard is to rebuild the kernel rather than getting the chroot environment to work?  The latter isn't giving me any luck and i have tried rebuilding all these packages with all kind of make.conf flag settings to no luck.

Why does the virtuals matter anyway, if i am only  trying to get root cli  on the filesystem with env and profile updates.

Why does it matter?

----------

## LIsLinuxIsSogood

Note, I have not yet attempted to rebuild the kernel but since i am getting impatient with the transfer i will take your suggestion and do.

----------

## LIsLinuxIsSogood

NEW PLAN:   If someone can please help to begin to explain why having the kernel ability to boot should or should not effect the rest of the software on my system that is currently the problem each time I go to chroot into the filesystem according to the instructions for chroot in the Handbook I am getting illegal instruction (code dump)....what is a new kernel or Grub going to do to change that? 

In case it helps, here is partition scheme for the disk I am looking to move....onto the older board w/ Pentium processor...NOTE: sda2 is formatted vfat (EFI boot partition with esp flags I believe) is the following :

```
sda      8:0    0 223.6G  0 disk 

|-sda4   8:4    0   223G  0 part /

|-sda2   8:2    0   128M  0 part 

|-sda3   8:3    0   512M  0 part [SWAP]

`-sda1   8:1    0     2M  0 part 
```

----------

## NeddySeagoon

LIsLinuxIsSogood,

The illegal instruction error tells that al least some of the code is built for a a different CPU to the one you are running that code on.

The kernel has nothing to do with it.

If you are trying to run bash in the chroot, then

```
 $ lddtree /bin/bash

/bin/bash (interpreter => /lib64/ld-linux-x86-64.so.2)

    libreadline.so.7 => /lib64/libreadline.so.7

        libncurses.so.6 => /lib64/libncurses.so.6

            libdl.so.2 => /lib64/libdl.so.2

    libc.so.6 => /lib64/libc.so.6
```

its one of those files causing the issue.

dmesg may give more clues.

----------

## LIsLinuxIsSogood

Ok I'll give it a try, here's something else I can't quite figure out...having rebuilt the kernel and now i'm stuck at trying to install GRUB on the previously formatted partition for EFI.

Update: I was able to launch a chroot by the help of reinstalling some of the libraries listed, which includes readline and ncurses

That's pretty much it for now!

EDIT: Starting new thread for another issue that I previously had included here for my mount issues with EFI boot partition

----------

## LIsLinuxIsSogood

Thanks to the last post I was able to find and fix the problem!  Thank you for being helpful in point me in the direction of the libraries that were missing for /bin/bash to run.

As mentioned in an earlier post, just chrooting is not really going to be enough, since I would like to have access to other programs now within the chroot...would this be an acceptable thing to try:

```
emerge -ave system emerge -ave world

```

The goal being to redo each piece of software for that generic case (amd64, in which -mtune=generic is the cflag in use)  would it make sense to now do emerge with use of the -e flag for that?

----------

