Toolchain updates #299
Toolchain updates #299
Conversation
The autoconfSync() function would reset the sources to their original state when used in an incremental build. This effectively broke incremental builds where autoconf and friends were run. Just resort to updates and keep new files.
Apparently, the "/" character was treated as comment character in assembler code. There is a --divide option to disable this behaviour. OTOH, it is disabled by default on Linux and many other systems too. We should match the new behaviour on L4Re as well.
The dynamic linker must have an absolute path. Otherwise it depends on the current working directory.
The bare metal compiler should report the same multilib list as the final compiler. This is required for newlib so that we know in which variants newlib has to be built.
Heavily inspired by the Arm toolchains...
Make it a full-featured toolchain with Cortex-A and -R support.
Regarding shared libs, L4Re behaves the same way as Linux. The previous patch did not set the SONAME of the library. This caused the library to be not found at runtime.
Apparently the support for stack smashing protection was broken.
No need to copy the files twice nowadays.
We copy the libraries that come from gcc into the sysroot so that they can be copied into the rootfs subsequently. Instead of making a fully copy, create hard links instead. This saves some space at least.
Not all target architectures are using the initfini-array approach to static construction/destruction. There is no need to set this option because gcc configure is smart enough to figure it out by itself. Forcing this option will cause strange build errors for mingw targets. Just remove it...
Add the possibility to use libs::mingw-w64 as libc. Interestingly, the mingw headers are already required at the bare compiler state. This requires a bit more refactoring just for this case.
Produces amd64 Windows binaries.
Our canadian cross build was not fully correct. We tried to cut some corners but this fails as soon as the architectures are vastly different. In the end, there is no other choice than to build all stages to the full extent. Also, we must not call any of the canadian cross binaries. The devel::cross-toolchain recipe did this to get some relative installation path. This must be removed as the binary might not be executable on the build machine.
Play nice and point people first to our bug tracker. This is the recommended way which is employed by all other (meta) distributions as well.
Hopefully removes some runtime overhead. At least most other distributions seem to set this switch so it cannot hurt to do it too.
When building a native cross compiler (build == host != target), the configure script added compiler flags to include sysroot directories from the installation directory. This is bad if a build sysroot was specified because the wrong files are potentially picked up.
We need to provide absolute paths to target binutils. The gcc configure would otherwise search them first at the installation prefix which is wrong for us. It does not seem to make much of a difference but we want to be safe.
This version of glibc apparently creates an endless loop with GNU make 4.4. See https://sourceware.org/pipermail/libc-help/2023-September/006486.html for one of the bug reports. Because we want to have this old glibc version, downgrading make seems to be the only viable option.
jkloetzke
force-pushed
the
toolchain-updates
branch
from
7567f43 to
f74a09d
Compare
Put the lever more on the performance side. This should only slightly increase the binary size but provide better performance for all host tools that are built. Also clean up the LDFLAGS. There is not much point in optimizing shared library symbol tables. Also, the preferred hash style is something that is better left to the binutils default. In case of our toolchains, it defaults to gnu hash style anyway.
This should provide better performance with only some slight size increase. If the system should be kept as small as possible, it is still possible to override the default.
Allow to control the way how gcc is built. In particular, the target-toolchain now controls whether debug infos are generated or which optimization level is used. So far, gcc always used its internal defaults (-O2 -g).
|
@rhubert Could you have a look at this? I'm not completely finished with testing but it somehow converges. There are at least the following changes that could cause trouble:
Let me know if this breaks something. |
|
Hmm...it breaks ada.. but this is expected. We need an ada compiler to build a ada compiler. These compilers must be of the same version, otherwise things break... Ada is a young language and not very stable 😠... - if [[ ${GCC_ENABLE_LANGUAGES:-c,c+} == *"ada"* ]]; then
- ADDITIONAL_MAKE=(all-gnattools)
- ADDITIONAL_INSTALL=(install-gnattools)
- fi
Also |
This was a deliberate change. Previously, we only built the compiler in devel::gcc-cross-canadian. Now we build everything in this package which should naturally include the ADA tools. At least that is my hope. Which brings me to the point: I briefly looked into building the ADA toolchain but quickly gave up. I think it would be good to have the ADA bootstrapping available and reproducible for everyone. Otherwise it's always hard to tell if some change breaks it.
I'll have a look. I was still debugging the mingw and L4Re toolchains... |
I'll add a test using the gnat-fsf toolchain to build a ada-cross toolchain and a ada-hello-world example based on this PR. If everything goes through it should be ready tomorrow... |
|
Here we are: https://github.com/rhubert/basement/tree/toolchain-updates%2Bada it works but needs some polishing... Maybe in the long term we can integrate the whole ada-layer into basement* / BobBuildTool namespace? |
Looks like this doesn't work. In |
🤦 they are prefixed... |
2 participants
No description provided.