That should definitely be possible to do. Please note that by default r5.0.3 will target armv8.2-a. You can adjust that targeting by adding an explicit -march argument to your SCons invocation. For instance, if you wanted to target e.g. armv8.1-a, you would say scons ... CCFLAGS=-march=armv8.1-a.
Yes, installing the pip requirements is the correct first step.
I think this is the root of your problem. When you are installing these python packages, you want them built for the local system, but by setting CC, CXX, etc you have pointed pythons packaging system to the cross compiler. That won’t work, for instance, when compiling any C language extensions that may be required by one of the packages being installed. I would recommend removing those cross compilation settings from the environment before running pip install, and I expect that the pip install command will work.
Note though that SCons generally does not consult the shell environment in furtherance of reproducible builds, so you don’t want those set in the shell for the SCons part of the build either. The correct way to pass things like your compiler in is via SCons command arguments. So, extrapolating a bit from your message, I’d expect your subsequent SCons command to look something like:
If you really must allow mutations of the shell environment to affect the behavior of SCons, e.g. for PATH, you can force it do to so by adding --variables-files=etc/scons/propagate_shell_environment.vars to your SCons invocation. I’d try to avoid that if possible though.
May I ask what platform you are targeting here? I’m asking because of xilinx in the toolchain name. I may be able to offer some other guidance, or save you some time if I know it won’t work.
Along with the question about what platform you are targeting, I would love to know more about your use case, if you don’t mind sharing. It is always helpful for us to have additional context on the different ways the community sources are being used in the real world.
-fstack-protector-strong: This is on by default in the server build.
-D_FORTIFY_SOURCE=2: This is on by default in the server build. Also, if is better to set preprocessor values via the CPPFLAGS SCons variable.
-Wformat -Wformat-security: We build by default with -Wall so you probably don’t need these. Overall, I recommend against passing in extra warning flags to the server build, as the set of warnings is very carefully managed.
-Werror=format-security: We build with -Werror by default. You can, if you need, suppress that by building with --disable-warnings-as-errors.
--sysroot=/home/siva/shiva/sdk_2021/.... If you are needing to do this for CCFLAGS, there is a good chance you will want to do it for LINKFLAGS as well, probably something like LINKFLAGS=-Wl,--sysroot,/home/siva/shiva/sdk_2021/....
You may also want to look into using the following flags for your build:
--separate-debug: Splits debug info out into separate files via gnu_debuglink sections. You may need to add OBJCOPY=/path/to/crosstools/objcopy for this to work.
--install-action=hardlink: Saves a little time copying the binaries into the installation directory since they can be large.
--opt=size: If you would prefer more compact code, this will build with -Os rather than -O2.
-j NUMJOBS: Use NUMJOBS parallel compile jobs. This makes a huge difference in build times.
Finally, which binaries do you need? Without specifying, you are perhaps going to build more than you actually need to. There are alias targets for several different tasks, including packaging up the build results into an archive.