Change-Id: I8084e0fa2ffbaf04242fa14617807d83abbd5586
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1556
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
We always want to use the shared one from the syslibs package,
never the shared one from this build.
Part of #14842: after this change, the ICU build now fails with
"cannot find libstdc++" instead of an invalid symbol.
This just stops the errors from occuring rather than trying to
rebuild the files at all. This is much cleaner, and solves
a few cases that the other method did not.
Our implementation of it now behaves properly after the last commit.
Change-Id: I6bebc91ae0f9512ea07ad6a7a4ccea9ee758e01b
Reviewed-on: https://review.haiku-os.org/c/908
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Previously they just silently continued, which meant that if part of the
cross-tools build failed, you would have to scroll back pretty far to
see what the failure was.
* Previously, the cross-compiler would generate code that doesn't
run on Haiku, particularly where TLS is concerned. It also ended
up with a c++config.h header incompatible with the version in
the native compiler.
* Now possible to correctly cross-compile rust for Haiku.
from a stock GDB source tree.
I was getting tired of doing it manually.
Note the prefix is not exactly the same as the buildtools since the
machine triplet is different, but it's not an issue.
Tested with arm and ppc with GDB 7.8. Might need patching gdbTarget for other archs,
as stock GDB doesn't know about Haiku.
* Drop unused variables from build system that refer to the system
libraries.
* Drop unused lists of libgcc objects.
* Drop no longer used variables from configuration script.
* Remove no longer needed building of kernel-libgcc and -libsupc++ from
build_cross_tools_gcc4, only the boot-specific (32-bit) libs are
built for a x86_64 target.
* Explicitly disable threads and TLS support when building the cross
compiler, as the only libraries that are used by Haiku's build system
is the 32-bit libgcc and libsupc++ for the bootloader on x86_64 (and
for that neither is wanted).
* Building gcc-4.8.3 on x86_64 with TLS support fails with an internal
compiler error. Until that problem is fixed, don't use TLS on x86_64,
which (due to libstdc++ compatibility) requires the same for the
host cross compiler.
Since hrev47198 we have ELF-based TLS support in Haiku. When building
gcc with haikuporter, this is detected by the configure script, but when
cross compiling gcc we need to manually enable it, as no runtime check
can be performed to detect the feature.
This should fix#10938 by avoiding the mix of TLS and non-TLS libstdc++.
Ideally, we would only need to set this in build/jam/board/*, but the
flags set there are not passed to the build of packages. The default is
using some early ARM variant, for which gcc lacks some more atomic
operations and emits calls to helper functions we don't implement.
Setting the default architecture avoids this, as all packages will now
be built to target the Cortex-A8.
Also set the proper VFP version in BeagleBoard config file.
Note this breaks the Verdex and Pi builds, but ARMv7 is what we should
focus on for now. We can try to make older archs work after finishing
the m68k port.
* This avoids mixup of the soft/hard float libs
* It also means we can use the hard-float libs for targets that supports
it
* Again, we could introduce an arm_softfp compiler for targets that
don't have floating point support, with a different gcc build.
* build kernel libgcc and libsupc++ with disabled posix threads for all
architectures. We currently change the configuration manually, as gcc
doesn't easily let us reconfigure without a full rebuild.
Pass --enable-hybrid-secondary to gcc's configure when building it as
a secondary compiler. Doesn't make a difference for building Haiku
itself, but makes it easier to match the Haiku cross devel package with
the compiler when building bootstrap packages with haikuporter.
gcc 4 only ATM.
The goal is to do hybrid builds in a single jam (instead of calling a
sub-jam to build parts with the secondary tool chain). This changeset
adds support to configure to prepare multiple tool chains.
configure:
* Merge option --build-cross-tools-gcc4 into --build-cross-tools. The
option does now always require a packaging architecture parameter,
i.e. x86_gcc2 for the legacy tool chain.
* Multiple occurrences of the --build-cross-tools and
--cross-tools-prefix options are allowed. The first one specifies the
primary tool chain, the subsequent ones the secondary tool chains.
* All architecture dependent jam variables are now suffixed with the
name of the packaging architecture. The new HAIKU_PACKAGING_ARCHS
contains the packaging architectures for the prepared tool chains. The
first element is for the primary tool chain.
* No longer generate a separate libgccObjects file. Just put the
respective variable into BuildConfig as well.
build_cross_tools[_gcc4]:
* Replace the <haiku output dir> parameter by a <install dir>
parameter. This allows to create different cross-tools directories.
They are simply suffixed by the packaging architecture.
Jamrules:
* For the moment map the variables for the primary tool chain to the
respective suffix-less variables, so that everything still works as
before.
The next step is to actually support the secondary tool chains in the
jam build system. This will require quite a bit more butchering, though.
* at least for gcc2, we used to leave the 'os' subfolder in there,
which may have caused problems when Haiku's headers have changed
since the last time the compiler was built.
(cherry picked from commit 92bb2fb33e)
* force creation of a cross-compiler for both gcc2 and gcc4 when
building on Haiku (by suffixing the build and host machine with
'_buildhost')
(cherry picked from commit df69e209bb)
Conflicts:
build/scripts/build_cross_tools_gcc4
* at least for gcc2, we used to leave the 'os' subfolder in there,
which may have caused problems when Haiku's headers have changed
since the last time the compiler was built.
