Best way to use native compiler along-side installed version?

[kcgen]

I'm attempting to build DOSBox from source using the native 8.3.0 build on a Pi3.

I've extracted the native gcc 8.3.0 build to /opt, and set the following environment variables:

OVERRIDE="/opt/native-pi-gcc-8.3.0-1/bin"
export AR="$OVERRIDE/gcc-ar-8.3.0"
export CC="$OVERRIDE/gcc-8.3.0"
export CXX="$OVERRIDE/g++-8.3.0"
export CPP="$OVERRIDE/cpp-8.3.0"
export FC="$OVERRIDE/gfortran-8.3.0"
export RANLIB="$OVERRIDE/gcc-ranlib-8.3.0"
export LD="$CXX"

For LTO builds, I additionally have:

CCPATH="/opt/native-pi-gcc-8.3.0-1/libexec/gcc/arm-linux-gnueabihf/8.3.0/"
export ARFLAGS="--plugin $GCCPATH/liblto_plugin.so"
export RANLIBFLAGS="--plugin $GCCPATH/liblto_plugin.so"

Attempting to ./configure with the above reports:

configure:3582: /opt/native-pi-gcc-8.3.0-1/bin/gcc-8.3.0    conftest.c  >&5
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory

I think the compiler should come with these files, but I didn't find them.
But I found copies in /usr/lib/arm-linux-gnueabihf, so I forced the linker to see them using:

export LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf

This progresses us to the next issue ./configure hits:

configure:3708: /opt/native-pi-gcc-8.3.0-1/bin/gcc-8.3.0 -o conftest    conftest.c  >&5
In file included from /usr/include/stdio.h:27,
                 from conftest.c:11:
/usr/include/features.h:364:12: fatal error: sys/cdefs.h: No such file or directory
 #  include <sys/cdefs.h>
            ^~~~~~~~~~~~~
compilation terminated.

The native build doesn't contain these headers, but I found them locally in /usr/include/arm-linux-gnueabihf:

CFLAGS="-I/usr/include/arm-linux-gnueabihf"
CXXFLAGS="-I/usr/include/arm-linux-gnueabihf"

This gets us passed that, but now we see these warnings:

configure: WARNING: png.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: png.h: proceeding with the compiler's result
...
configure: WARNING: SDL_net.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: SDL_net.h: proceeding with the compiler's result
...
configure: WARNING: X11/XKBlib.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: X11/XKBlib.h: proceeding with the compiler's result
...
and so on.

At this point, it feels too off the rails.

I'm hoping I've doing wrong - maybe there's a more seamless approach? - symlinks? PATH override? copying some portion overtop /usr/...? Happy to try any suggestions.

Much thanks for the nice organized builds!
I want to report the cross-compiler is working perfectly, and I'm running an 8.3 cross-compiled build of the latest 4.19 kernel.

[abhiTronix]

@krcroft

Attempting to ./configure with the above reports:

configure:3582: /opt/native-pi-gcc-8.3.0-1/bin/gcc-8.3.0 conftest.c >&5
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory

Did you strictly followed the linking step carefully? Especially these steps:

5. Manage Important Links as below:

sudo ln -s /usr/include/arm-linux-gnueabihf/sys /usr/include/sys   
sudo ln -s /usr/include/arm-linux-gnueabihf/bits /usr/include/bits   
sudo ln -s /usr/include/arm-linux-gnueabihf/gnu /usr/include/gnu   
sudo ln -s /usr/include/arm-linux-gnueabihf/asm /usr/include/asm   
sudo ln -s /usr/lib/arm-linux-gnueabihf/crti.o /usr/lib/crti.o   
sudo ln -s /usr/lib/arm-linux-gnueabihf/crt1.o /usr/lib/crt1.o   
sudo ln -s /usr/lib/arm-linux-gnueabihf/crtn.o /usr/lib/crtn.o 

Also,

I think the compiler should come with these files, but I didn't find them.
But I found copies in /usr/lib/arm-linux-gnueabihf, so I forced the linker to see them using:

export LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf

Wrong LIBRARY_PATH again!

Solution:

Restart your Pi and clean your Build folder and fresh install/link GCC 8.3.0 strictly follow instructions stated in wiki with no extra flags except these:

OVERRIDE="/opt/native-pi-gcc-8.3.0-1/bin"
export AR="$OVERRIDE/gcc-ar-8.3.0"
export CC="$OVERRIDE/gcc-8.3.0"
export CXX="$OVERRIDE/g++-8.3.0"
export CPP="$OVERRIDE/cpp-8.3.0"
export FC="$OVERRIDE/gfortran-8.3.0"
export RANLIB="$OVERRIDE/gcc-ranlib-8.3.0"

and re-run the ./configure command.

[kcgen]

Worked flawlessly! and huge apologies; I didn't see your wiki article. Thank you!

Some super minor comments that might be useful for the wiki:

I would suggest putting the PATH and LD_LIBRARY_PATH settings in .profile instead of .bashrc.

bashrc is for interactive shells and (and its top-level logic will exit if the shell is non-interactive, such as for terminal-less sessions or automated runs launched from a system call). Also, bash re-sources .bashrc for every subshell - so you wind up with one duplicate PATH entry for every level of subshell entered (autotools scripts can go many deep).

"export" (in the PATH statement) is uneeded because the shell already defines PATH by the time it gets to the users rc files. All that's needed is PATH=xyz, which updates the variable regardless of scope. That said, export is needed for LD_LIBRARY_PATH because it's usually not yet defined.

Here's what I have in my .profile:

PATH="/opt/native-pi-gcc-8.3.0-1/bin:$PATH"
export LD_LIBRARY_PATH=/opt/native-pi-gcc-8.3.0-1/lib

(I deliberately don't want to build on LD_LIBRARY_PATH because I want to control it exactly)

With PATH defined, here are my autotools overrides:

export AR="gcc-ar-8.3.0"
export CC="gcc-8.3.0"
export CXX="g++-8.3.0"
export CPP="cpp-8.3.0"
export FC="gfortran-8.3.0"
export RANLIB="gcc-ranlib-8.3.0"
export LD="$CXX"

Link-time-optimization (LTO) works great too! Your GCC build is excellent. Here's how to use that:

GCCPATH="/opt/native-pi-gcc-8.3.0-1/libexec/gcc/arm-linux-gnueabihf/8.3.0"
export ARFLAGS="--plugin $GCCPATH/liblto_plugin.so"
export RANLIBFLAGS="--plugin $GCCPATH/liblto_plugin.so"

LTO also needs g++ to be the linker (so export LD="$CXX" per above), and it's enabled at compile-time by setting these -flto=$(nproc) -fno-fat-lto-objects arguments in your CFLAGS, CXXFLAGS, and LDFLAGS.

Also, one last strange one (if someone also hits it) -- when building Xiph's Opus library, I hit this error:

/usr/include/bits/stdlib.h: In function ‘wctomb’:
/usr/include/bits/stdlib.h:90:3: error: #error "Assumed value of MB_LEN_MAX wrong"
 # error "Assumed value of MB_LEN_MAX wrong"
   ^~~~~

What's very strange is I couldn't find a header on the system or in my package source trees that were setting MB_LEN_MAX to anything other than 16. So I kludged around it with:

#define __STDLIB_MB_LEN_MAX     16
#if defined MB_LEN_MAX
  #undef MB_LEN_MAX
  #define MB_LEN_MAX 16
#endif

Thanks again for the fast and critical help with this!

[abhiTronix]

I would suggest putting the PATH and LD_LIBRARY_PATH settings in .profile instead of .bashrc.

bashrc is for interactive shells and (and its top-level logic will exit if the shell is non-interactive, such as for terminal-less sessions or automated runs launched from a system call). Also, bash re-sources .bashrc for every subshell - so you wind up with one duplicate PATH entry for every level of subshell entered (autotools scripts can go many deep).

"export" (in the PATH statement) is uneeded because the shell already defines PATH by the time it gets to the users rc files. All that's needed is PATH=xyz, which updates the variable regardless of scope. That said, export is needed for LD_LIBRARY_PATH because it's usually not yet defined.

Here's what I have in my .profile:

PATH="/opt/native-pi-gcc-8.3.0-1/bin:$PATH"
export LD_LIBRARY_PATH=/opt/native-pi-gcc-8.3.0-1/lib

(I deliberately don't want to build on LD_LIBRARY_PATH because I want to control it exactly)

With PATH defined, here are my autotools overrides:

export AR="gcc-ar-8.3.0"
export CC="gcc-8.3.0"
export CXX="g++-8.3.0"
export CPP="cpp-8.3.0"
export FC="gfortran-8.3.0"
export RANLIB="gcc-ranlib-8.3.0"
export LD="$CXX"

Link-time-optimization (LTO) works great too! Your GCC build is excellent. Here's how to use that:

GCCPATH="/opt/native-pi-gcc-8.3.0-1/libexec/gcc/arm-linux-gnueabihf/8.3.0"
export ARFLAGS="--plugin $GCCPATH/liblto_plugin.so"
export RANLIBFLAGS="--plugin $GCCPATH/liblto_plugin.so"

LTO also needs g++ to be the linker (so export LD="$CXX" per above), and it's enabled at compile-time by setting these -flto=$(nproc) -fno-fat-lto-objects arguments in your CFLAGS, CXXFLAGS, and LDFLAGS.

@krcroft Thanks for this valuable information, I'll update the wiki accordingly. Much appreciated 🥇 . But export command with PATH variable is necessary in our case as Exported variables get passed on to child processes, not-exported variables do not. and we want the latter in our case. More information here

Much thanks for the nice organized builds!
I want to report the cross-compiler is working perfectly, and I'm running an 8.3 cross-compiled build of the latest 4.19 kernel.

Also, could you write this above comment as a review at sourceforge Or 🌟 this repository. That will help others more to easily find/trust these binaries and this project. Thank you in Advance 😃

[kcgen]

Absolutely!

• Starred on github
• 5-Stared on SF + Review

Regarding:

But export command with PATH variable is necessary in our case as Exported variables get passed on to child processes, not-exported variables do not. and we want the latter in our case.

It's not needed. Try it yourself on the command line then launch a subshell ("bash") and see if your changes persisted. You will see that your PATH changes persist into subprocesses without using export.

This is because the top-level Shell already defines the PATH variable at the environment-level, and "PATH=xyz" simply changes that variable (whatever level it might be). Because PATH was originally defined at the environment level, it will continue to stay at that level regardless of the number of times it's changed.

Here's an example:

pi@retropie:~ $ echo $PATH
/opt/native-pi-gcc-8.3.0-1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
pi@retropie:~ $ PATH="/testing123:$PATH"
pi@retropie:~ $ bash

     .***.     Tuesday, 12 March 2019, 06:13:37 PM
     *****     Linux 4.19.27-300hz-fulltickless-preempt-v7-stripped armv7l GNU/Linux
     `***'     
      |*|      Filesystem      Size  Used Avail Use% Mounted on
      |*|      /dev/root       120G  115G  4.8G  96% /
    ..|*|..    Uptime.............: 1 days, 02h29m14s
  .*** * ***.  Memory.............: 49260kB (Free) / 837504kB (Total)
  *******@@**  Running Processes..: 122
  `*****@@**'  IP Address.........: 192.168.1.100
   `*******'   Temperature........: CPU: 44°C/111°F GPU: 44°C/111°F
     `"""'     The RetroPie Project, https://retropie.org.uk

pi@retropie:~ $ echo $PATH
/testing123:/opt/native-pi-gcc-8.3.0-1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
pi@retropie:~ $ 

Cheers!

[abhiTronix]

@krcroft

It's not needed. Try it yourself on the command line then launch a subshell ("bash") and see if your changes persisted. You will see that your PATH changes persist into subprocesses without using export.

This is because the top-level Shell already defines the PATH variable at the environment-level, and "PATH=xyz" simply changes that variable (whatever level it might be). Because PATH was originally defined at the environment level, it will continue to stay at that level regardless of the number of times it's changed.

Yes, you are absolutely right, I may have interpreted it wrong in the first place. I think both will work and we should use whichever is comfortable. Neither makes any difference functionally, so this is primarily a question of style. I may leave this to the users to decide whichever they like and already mentioned this conversation in the wiki section. Kudos!

Also, again thank you so much for supporting this project. Much appreciated

[PR8KW]

Hi, I like to compile a g++8 project on Raspbian stretch RPI 3B.
I try to follow the temporary native compiler instruction...
I download version native-gcc-8.3.0-pi_2-3.tar.gz and extract to /opt/native-pi-gcc-8.3.0-1

My commands:
`PATH=/opt/native-pi-gcc-8.3.0-1/bin:$PATH
LD_LIBRARY_PATH=/opt/native-pi-gcc-8.3.0-1/lib:$LD_LIBRARY_PATH

sudo ln -sf /usr/include/arm-linux-gnueabihf/asm /usr/include/asm
sudo ln -sf /usr/include/arm-linux-gnueabihf/gnu /usr/include/gnu
sudo ln -sf /usr/include/arm-linux-gnueabihf/bits /usr/include/bits
sudo ln -sf /usr/include/arm-linux-gnueabihf/sys /usr/include/sys
sudo ln -sf /usr/include/arm-linux-gnueabihf/openssl/* /usr/include/openssl
sudo ln -sf /usr/lib/arm-linux-gnueabihf/crtn.o /usr/lib/crtn.o
sudo ln -sf /usr/lib/arm-linux-gnueabihf/crt1.o /usr/lib/crt1.o
sudo ln -sf /usr/lib/arm-linux-gnueabihf/crti.o /usr/lib/crti.o

export AR="gcc-ar-8.3.0"
export CC="gcc-8.3.0"
export CXX="g++-8.3.0"
export CPP="cpp-8.3.0"
export FC="gfortran-8.3.0"
export RANLIB="gcc-ranlib-8.3.0"
export LD="$CXX"

GCCPATH="/opt/native-pi-gcc-8.3.0-1/libexec/gcc/arm-linux-gnueabihf/8.3.0"
export ARFLAGS="--plugin $GCCPATH/liblto_plugin.so"
export RANLIBFLAGS="--plugin $GCCPATH/liblto_plugin.so"`

But error when try to compile:
`$ make ubxtool navdump
protoc --cpp_out=./ navmon.proto
g++-8.3.0 -std=gnu++17 -Wall -O3 -MMD -MP -ggdb -fno-omit-frame-pointer -Iext/CLI11 -Iext/fmt-5.2.1/include/ -Iext/powerblog/ext/simplesocket -Iext/powerblog/ext/ -I/usr/local/opt/openssl/include/ -Iext/sgp4/libsgp4/ -I/usr/local/include -c -o navmon.pb.o navmon.pb.cc
In file included from /opt/native-pi-gcc-8.3.0-1/include/c++/8.3.0/arm-linux-gnueabihf/bits/os_defines.h:39,
from /opt/native-pi-gcc-8.3.0-1/include/c++/8.3.0/arm-linux-gnueabihf/bits/c++config.h:508,
from /opt/native-pi-gcc-8.3.0-1/include/c++/8.3.0/string:38,
from navmon.pb.h:7,
from navmon.pb.cc:5:
/usr/include/features.h:364:12: fatal error: sys/cdefs.h: Arquivo ou diretório não encontrado

include <sys/cdefs.h>

        ^~~~~~~~~~~~~

compilation terminated.
: recipe for target 'navmon.pb.o' failed
make: *** [navmon.pb.o] Error 1
`

Many thanks.

[abhiTronix]

@PR8KW Kindly print the output of the following command from your raspberry pi terminal here:

tree  /usr/include/sys

[PR8KW]

@abhiTronix Hi, please found results.

$ tree /usr/include/sys
tree /usr/include/sys
/usr/include/sys
├── asoundlib.h
└── sys -> /usr/include/arm-linux-gnueabihf/sys

Many Thanks

[abhiTronix]

@abhiTronix Hi, please found results.

$ tree /usr/include/sys tree /usr/include/sys /usr/include/sys ├── asoundlib.h └── sys -> /usr/include/arm-linux-gnueabihf/sys

@PR8KW This a wrong output. Can you try these new commands in your Pi terminal instead:

PATH=/opt/native-pi-gcc-8.3.0-1/bin:$PATH
LD_LIBRARY_PATH=/opt/native-pi-gcc-8.3.0-1/lib:$LD_LIBRARY_PATH

sudo ln -sf /usr/include/arm-linux-gnueabihf/asm/* /usr/include/asm
sudo ln -sf /usr/include/arm-linux-gnueabihf/gnu/* /usr/include/gnu
sudo ln -sf /usr/include/arm-linux-gnueabihf/bits/* /usr/include/bits
sudo ln -sf /usr/include/arm-linux-gnueabihf/sys/* /usr/include/sys
sudo ln -sf /usr/include/arm-linux-gnueabihf/openssl/* /usr/include/openssl
sudo ln -sf /usr/lib/arm-linux-gnueabihf/crtn.o /usr/lib/crtn.o
sudo ln -sf /usr/lib/arm-linux-gnueabihf/crt1.o /usr/lib/crt1.o
sudo ln -sf /usr/lib/arm-linux-gnueabihf/crti.o /usr/lib/crti.o

export AR="gcc-ar-8.3.0"
export CC="gcc-8.3.0"
export CXX="g++-8.3.0"
export CPP="cpp-8.3.0"
export FC="gfortran-8.3.0"
export RANLIB="gcc-ranlib-8.3.0"
export LD="$CXX"

GCCPATH="/opt/native-pi-gcc-8.3.0-1/libexec/gcc/arm-linux-gnueabihf/8.3.0"
export ARFLAGS="--plugin $GCCPATH/liblto_plugin.so"
export RANLIBFLAGS="--plugin $GCCPATH/liblto_plugin.so"`

and see if your program compiled successfully without errors? I'm waiting for your feedback.