It is just straight up broken on most systems without this, as
the same "cast specifies signature type" appears there too.
Exactly why this fixes the problem does not appear to be any more known
than it was when this was first instated in 2012.
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.
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
GCC 2 built for OS X 10.7/10.8 was broken, the Haiku build would fail
with some strange errors. Forcing compilation of GCC 2 in 32-bit mode
results in a working GCC.
* Apparently caused by the fact that we no longer run fixincludes,
math.h is not being generated anymore. I haven't removed the rm
from the script in order to be compatible with older compilers.
influencing this script.
* If haikuRequiredLegacyGCCVersion has not been specified, assume that
the script was called manually and just use the version string from
the gcc sources.
* Make error output a bit more consistent.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43163 a95241bf-73f2-0310-859d-f6bbb57e9c96
trying to build the compiler when it's not going to work
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38384 a95241bf-73f2-0310-859d-f6bbb57e9c96
only -jN and gcc's build system has problems with multiple jobs. It works
fine for binutils and gcc 4 though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34990 a95241bf-73f2-0310-859d-f6bbb57e9c96
and types.h. The idea is to provide a basic architecture/compiler
abstraction by defining types and macros that allow the posix/ and os/
headers to be mostly architecture/compiler agnostic.
* Adjusted the posix/ and os/ headers accordingly.
* <SupportDefs.h>: Introduced B_PRI* and B_SCN* macros similar to the PRI*
and SCN* macros defined in <inttypes.h>, just for the BeOS/Haiku [u]int*
types and some POSIX types (e.g. off_t, dev_t, ino_t) that don't have POSIX
macros. Also the B_PRI* and B_SCN* macros are available unconditionally,
unlike the <inttypes.h> macros, which require __STDC_FORMAT_MACROS to be
defined in C++ mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34214 a95241bf-73f2-0310-859d-f6bbb57e9c96
build_cross_tools[_gcc4] script which in turn passes it to make. Cores and
hyperthreads are plentiful these days; no need to let most of them idle when
building the cross tools.
* Sorted the configure options alphabetically again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34199 a95241bf-73f2-0310-859d-f6bbb57e9c96
apparently is enabled by default on newer Ubuntu versions and breaks the
gcc build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28396 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added sunos to the list of platforms, but it needs more work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24922 a95241bf-73f2-0310-859d-f6bbb57e9c96
gcc. You need to reconfigure and rebuild the cross-tools to have this
change take effect.
Note that from now on it is no longer possible to use the native BeOS
compiler to build Haiku. You'll have to build a cross compiler, too. I
haven't tested whether this works at all, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24542 a95241bf-73f2-0310-859d-f6bbb57e9c96
hack math_huge_val_ifndef does, anyway. We do it ourselves and remove
the therefore superfluous gcc math.h header.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24412 a95241bf-73f2-0310-859d-f6bbb57e9c96
in separate folders ('cross-tools-legacy' and 'cross-tools-gcc4') and you
can use the new cmdline-switches 'use-cross-tools' and 'use-cross-tools-gcc4'
to switch between those two. Before, you always had to recompile the tools
in order to switch.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18985 a95241bf-73f2-0310-859d-f6bbb57e9c96
building of cross-compiler on Linux (as reported by korli, thanks!).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18861 a95241bf-73f2-0310-859d-f6bbb57e9c96
