cross_tools: allow specifying a custom sysroot path

* Use with --sysroot /path/to/sysroot; useful for CI
environments and cross-building.

Change-Id: I27a93a5d209cd5324591587e85fce9b47c18172d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5318
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

build/cross_tools_gcc4: explicit disable libatomic and libgomp

Change-Id: If8cad96420cd249106c611aaf59353adab1271ee
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3897
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

Add -std=c++14 to build_cross_tools_gcc4

CLang fails to build ISL otherwise, and if you are setting up
cross compiling, you should have a modern enough compiler

Fixes #16434

Change-Id: Ieb4a33015899896ea3bb2d1abc59b10fe0b4b3f2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3730
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>

build/cross-tools: explicitly set ISA for riscv64

* Enable TLS for riscv64. For now select a dummy
implementation.
* RISC-V has a register (tp) dedicated to TLS
* All the "desktop-like" RV64 chipsets implement GC
* Same ISA we currently build for... but calls it out
in-case defaults change.

Change-Id: I623b6e5c309b6a6e80ec378e456b2335c561269d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3632
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

build/cross_tools_gcc4: x86_64, explicit enable-multilib

* This was originally added circa 2012. via hrev43954
* Our toolchain appears to work fine now with explicit
multilib enabled.

Change-Id: I1f5d55c63a6b3b6ab1c4db95da3d14d5ef2da0df
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3315
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

Remove graphite building, we have gcc with these deps in build

When we moved ISL, MPFR, GMP and so on inside GCC we no longer
need to do any specific building to support graphite.

build/scripts: make toolchain scripts more self-sustainable

Change-Id: Ibe4cf105a20184392498371ba770529d69bd61a7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2417
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

buildtools: Disable tls on riscv64 for now

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>

build_cross_tools_gcc4: Keep static libstdc++, but rename it.

The gcc_bootstrap recipe still needs it, it seems.

build_cross_tools_gcc4: Remove the generated static libstdc++.

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.

build_cross_tools_gcc4: Handle $PATH having spaces in it properly.

Fixes the build of the cross tools under WSL.

build_cross_tools_gcc4: Clear "missing" scripts instead of touching files.

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.

build_cross_tools_gcc4: Enable initfini-array in binutils.

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>

build_cross_tools: export ACLOCAL to stop GCC from trying to use it.

This should fix the build of the crosstools on Haiku, CentOS, and
other platforms with versions of autofools too old or too new for
GCC 7.

build_cross_tools: Also touch .in files to prevent their regeneration.

Change-Id: Id893460327fd6db064c6fc0fb4de8e6ada1b1773
Reviewed-on: https://review.haiku-os.org/496
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

build_cross_tools: Touch configure scripts so the Makefiles don't regenerate them.

build_cross_tools_gcc4: Forcibly disable maintainer mode.

This should stop GCC from trying to reconfigure.

build_cross_tools: Have scripts exit on failure.

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.

build_cross_tools_gcc4: Disable TLS on PowerPC for now

Change-Id: Ib99a1a4aeeb5d17a301ffd1d9c5fcadd37261ebf

build_cross_tools_gcc4: bring in sync with native compiler.

* 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.

Update binutils_x86 and binutils for x86_gcc2 and x86_64.

* starting with 2.27, binutils defaults to initfini-array instead of init and fini,
this leads to problems in Haiku, just disable for the time being.

configure: pass proper gdb target for m68k

configure: allow building GDB along with the buildtools

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.

typo

build_cross_tools_gcc4: disable libatomic.

Try to fix the ARM cross-tools build

* Gcc5 does not allow both --with-arch and --with-cpu anymore, so use just --with-cpu.

Build binutils with different extra targets depending on arch

EFI support isn't much useful for ARM.

Also add some targets to help debugging binutils on PPC.

Cleanup build system and configuration.

* 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).

Re-enable TLS on x86_64 when cross-building.

Building gcc on x86_64 with TLS enabled has been fixed,
so this is to keep cross-builds and native builds in
sync.

Fixed hrev47542 changeset to become sh compatible.

Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>

Disable building gcc with TLS support since ARM build fails due to undefined references

Build libsupc++-kernel without TLS

Disable TLS support on x86_64 explicitly.

* 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.

Enable TLS support in gcc.

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++.

Whitespace cleanup in root and 'build' folder.

* Removed trailing whitespace and empty lines at top of files.

Configure the ARM compiler to default to Cortex-A8

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.

Disable multilib for the ARM compiler build.

* 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.

configure: --use-gcc-pipe now affects build_cross_tools_gcc4.

build_cross_tools_gcc4: enable posix threads.

* 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.

build_cross_tools_gcc4: unbreak --use-gcc-graphite.

* added -pipe to CFLAGS, builds are faster and /tmp usage is avoided at the
cost of more memory used.
* replaced ppl by isl as required by gcc 4.8

Fix for whitespace in paths

Signed-off-by: Ingo Weinhold <ingo_weinhold@gmx.de>

Use uname -s instead of uname -o

...since BSD uname (on OS X at least) doesn't have a -o param, only a -s,
Haiku has both, and both print "Haiku".

Use uname -s instead of uname -o

...since BSD uname (on OS X at least) doesn't have a -o param, only a -s,
Haiku has both, and both print "Haiku".

Enable targets for EFI on binutils.

objcopy needs to know about EFI targets if we want to build EFI Applications.
Also minor whitespace removal.

Use GNU make also for building gcc 2

Should fix the build on {Free,Open}BSD.

build_cross_tools_gcc4: use --with-hybrid-secondary

Build the cross gcc for the secondary arch as such

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.

build_cross_tools_gcc4: move sysroot dir into install dir

This allows us to sneak in system include and library search dirs in
haikuporter without doing anything outside the cross tools dir.

configure: prepare for hybrid support

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.

Remove whole sys-include folder when cross-compiler has been built.

* 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 92bb2fb33e2d0f4aa766be095057fe63ff17bc8e)

Fix #7824: failure to build a cross-compiler on Haiku.

* 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 df69e209bbacd07fdfea9d9efcfc8e1c0dfedaa0)

Conflicts:
build/scripts/build_cross_tools_gcc4

Remove whole sys-include folder when cross-compiler has been built.

* 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.

Fix #7824: failure to build a cross-compiler on Haiku.

* force creation of a cross-compiler for both gcc2 and gcc4 when
building on Haiku (by suffixing the build and host machine with
'_buildhost')

Adjust buildscript for gcc4 to configure with a sysroot.

style clean up

GCC4 cross tools: fixes the build with --use-gcc-graphite on another machine

* libsupc++ wasn't required, the build failed on x86_64.
* PPL: --disable-maintainer-mode configure option seems not enough to avoid an autoconf launch.
Solved by redefined AUTOCONF AUTOHEADER ACLOCAL AUTOMAKE variables to the noop command "true".

GCC4 cross tools: a static libGMP requires linking with the host libstdc++

GCC4 cross tools: build libGMP before PPL and CLooG

* libGMP is actually a CLooG dependency, we now build it before CLooG
and tell to GCC where to find it when Graphite build is activated.

GCC4 cross tools: disable "maintainer mode" on PPL configure.

* PPL: make could run autoconf in certain conditions, thus generating artefacts
in the source tree. Added --disable-maintainer-mode when launching
configure to avoid this situation.
* cleanup: there are no info files in CLooG and PPL.

GCC4 cross tools: builds with ppl and cloog when --use-gcc-graphite is given

Force POSIX-locale when building the buildtools

* using a non-POSIX locale may break the build (especially makeinfo),
so we explicitly set the locale to POSIX

Cleanup of remains of subversion in the build system

Do a separate libgcc build for the kernel as well.

Turns out that libgcc is needed, for some reason building the kernel
with -O0 does not end up referencing libgcc but -O2 does. A separate
build of it is done with -mno-red-zone, same reason as for libsupc++.
Ended up being easy to rebuild with different CFLAGS: previously I'd
tried doing `CFLAGS="-mno-red-zone" make` in the libgcc dir which
didn't override, the correct way is `make CFLAGS="-mno-red-zone"`

Build a separate libsupc++ for the kernel with correct flags.

Kernel mode code on x86_64 needs to be built with -mno-red-zone as
interrupts would corrupt the red zone if it were in use. However, the
kernel is linked with libsupc++, which was not compiled with
-mno-red-zone. If an interrupt occurred in libsupc++ code the red zone
would get corrupted. This was causing random panics, particularly under
heavy system load. Therefore, on x86_64 a separate build of libsupc++
with -mno-red-zone is now done for the kernel to use. Note: this commit
will require a rerun of configure and rebuild of cross tools.

use system zlib when cross building gcc4 to fix #8242

* this add a dependency on package zlib1g-dev for Linux systems.

Fixed a compilation failure for the x86_64 toolchain.

This appears to be a problem with GCC's build system: it defaults to having
multilib enabled, but if it is explicitly enabled with --enable-multilib,
the build fails.

Signed-off-by: Ingo Weinhold <ingo_weinhold@gmx.de>

Added workarounds and options for gcc 4.6.2

* add -Wno-unused-but-set-variable for gcc 4.6.x with a TODO
* fix warnings about wrong size of pointer cast in ioapic.cpp and AudioBuffer.cpp

Closing #8063:
* touch all .info files before trying to build the gcc4
buildtools in order to avoid the dependency on makeinfo.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43012 a95241bf-73f2-0310-859d-f6bbb57e9c96

Replace the $(...) syntax with backticks instead.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41721 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Nathan Mentley: Build the x86-64 build tools with multilib support.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37522 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced new header directory "config", which ATM contains HaikuConfig.h
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

* Added -j<n> option to configure. It is passed to the
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

Don't know why multilib was disabled in r29035, but we'll likely need it for arm, and m68k as well...
Make it depend on haikuMachine.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32213 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Alexander von Gluck (kallisti5) to get the PPC build going again
(mostly at least). Also disables -Werror for the binutils, but those should
be fixed eventually.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29804 a95241bf-73f2-0310-859d-f6bbb57e9c96

Forgot to update this reference when renaming be/ to os/.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29069 a95241bf-73f2-0310-859d-f6bbb57e9c96

The default include paths have been updated from be/ to os/ so copy correspondingly.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29057 a95241bf-73f2-0310-859d-f6bbb57e9c96

Updating config for current GCC4 cross compiler.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29035 a95241bf-73f2-0310-859d-f6bbb57e9c96

- Have OpenBSD use gmake
- export MAKE to make sure submakes use it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28250 a95241bf-73f2-0310-859d-f6bbb57e9c96

gcc 4.1.2 conveniently saves the version number in a separate file.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20319 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added shebang. Should fix bug #956.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20062 a95241bf-73f2-0310-859d-f6bbb57e9c96

* reverted changes of revision 18985, as Ingo has pointed out, they were useless.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18994 a95241bf-73f2-0310-859d-f6bbb57e9c96

* implemented a suggestion of korli: the legacy & gcc4 cross-tools are now built
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

Adjusted build_cross_tools_gcc4 and configure to be able to build PPC
build tools as well. The configure option --build-cross-tools-gcc4 has a
new parameter to specify the architecture.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15382 a95241bf-73f2-0310-859d-f6bbb57e9c96

When building the gcc 4 cross tools we now configure for machine
i586-pc-haiku.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15345 a95241bf-73f2-0310-859d-f6bbb57e9c96

Adjusted build_cross_tools[_gcc4] scripts according to the new directory
layout in the buildtools module.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15083 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moved FreeBSD setup to define a freebsd build platform. GCC4 apparently also requires the use of GNU Make, so told the build_cross_tools script to use 'gmake' instead of 'make' on BSD systems.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15024 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added build_cross_tools_gcc4 script which builds gcc 4 and binutils
from the sources. Added respective configure option
--build-cross-tools-gcc4.
* Fixed running "configure --build-cross-tools" from another directory
than the source dir. The parameter to the script was missing and thus
the tools were created in <sources>/generated.
* Removed stdc++ lib header dir ".../debug". One is supposed to include
<debug/...> to get the debug headers.
* The stdc++ lib header dirs are now listed one per line in the
generated BuildConfig. This works around the 512 bytes jam line length
limit.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15020 a95241bf-73f2-0310-859d-f6bbb57e9c96

Build binutils with different extra targets depending on arch

EFI support isn't much useful for ARM.

Also add some targets to help debugging binutils on PPC.

Cleanup build system and configuration.

* 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).

Re-enable TLS on x86_64 when cross-building.

Building gcc on x86_64 with TLS enabled has been fixed,
so this is to keep cross-builds and native builds in
sync.

Fixed hrev47542 changeset to become sh compatible.

Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>

Disable building gcc with TLS support since ARM build fails due to undefined references

Build libsupc++-kernel without TLS

Disable TLS support on x86_64 explicitly.

* 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.

Enable TLS support in gcc.

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++.

Whitespace cleanup in root and 'build' folder.

* Removed trailing whitespace and empty lines at top of files.

Configure the ARM compiler to default to Cortex-A8

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.

Disable multilib for the ARM compiler build.

* 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.

configure: --use-gcc-pipe now affects build_cross_tools_gcc4.

build_cross_tools_gcc4: enable posix threads.

* 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.

build_cross_tools_gcc4: unbreak --use-gcc-graphite.

* added -pipe to CFLAGS, builds are faster and /tmp usage is avoided at the
cost of more memory used.
* replaced ppl by isl as required by gcc 4.8

Fix for whitespace in paths

Signed-off-by: Ingo Weinhold <ingo_weinhold@gmx.de>

Use uname -s instead of uname -o

...since BSD uname (on OS X at least) doesn't have a -o param, only a -s,
Haiku has both, and both print "Haiku".

Use uname -s instead of uname -o

...since BSD uname (on OS X at least) doesn't have a -o param, only a -s,
Haiku has both, and both print "Haiku".

Enable targets for EFI on binutils.

objcopy needs to know about EFI targets if we want to build EFI Applications.
Also minor whitespace removal.

Use GNU make also for building gcc 2

Should fix the build on {Free,Open}BSD.

build_cross_tools_gcc4: use --with-hybrid-secondary

Build the cross gcc for the secondary arch as such

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.

build_cross_tools_gcc4: move sysroot dir into install dir

This allows us to sneak in system include and library search dirs in
haikuporter without doing anything outside the cross tools dir.

configure: prepare for hybrid support

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.

Remove whole sys-include folder when cross-compiler has been built.

* 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 92bb2fb33e2d0f4aa766be095057fe63ff17bc8e)

Fix #7824: failure to build a cross-compiler on Haiku.

* 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 df69e209bbacd07fdfea9d9efcfc8e1c0dfedaa0)

Conflicts:
build/scripts/build_cross_tools_gcc4

Remove whole sys-include folder when cross-compiler has been built.

* 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.

Fix #7824: failure to build a cross-compiler on Haiku.

* force creation of a cross-compiler for both gcc2 and gcc4 when
building on Haiku (by suffixing the build and host machine with
'_buildhost')

Adjust buildscript for gcc4 to configure with a sysroot.

style clean up

GCC4 cross tools: fixes the build with --use-gcc-graphite on another machine

* libsupc++ wasn't required, the build failed on x86_64.
* PPL: --disable-maintainer-mode configure option seems not enough to avoid an autoconf launch.
Solved by redefined AUTOCONF AUTOHEADER ACLOCAL AUTOMAKE variables to the noop command "true".

GCC4 cross tools: a static libGMP requires linking with the host libstdc++

GCC4 cross tools: build libGMP before PPL and CLooG

* libGMP is actually a CLooG dependency, we now build it before CLooG
and tell to GCC where to find it when Graphite build is activated.

GCC4 cross tools: disable "maintainer mode" on PPL configure.

* PPL: make could run autoconf in certain conditions, thus generating artefacts
in the source tree. Added --disable-maintainer-mode when launching
configure to avoid this situation.
* cleanup: there are no info files in CLooG and PPL.

GCC4 cross tools: builds with ppl and cloog when --use-gcc-graphite is given

Force POSIX-locale when building the buildtools

* using a non-POSIX locale may break the build (especially makeinfo),
so we explicitly set the locale to POSIX

Cleanup of remains of subversion in the build system

Do a separate libgcc build for the kernel as well.

Turns out that libgcc is needed, for some reason building the kernel
with -O0 does not end up referencing libgcc but -O2 does. A separate
build of it is done with -mno-red-zone, same reason as for libsupc++.
Ended up being easy to rebuild with different CFLAGS: previously I'd
tried doing `CFLAGS="-mno-red-zone" make` in the libgcc dir which
didn't override, the correct way is `make CFLAGS="-mno-red-zone"`

Build a separate libsupc++ for the kernel with correct flags.

Kernel mode code on x86_64 needs to be built with -mno-red-zone as
interrupts would corrupt the red zone if it were in use. However, the
kernel is linked with libsupc++, which was not compiled with
-mno-red-zone. If an interrupt occurred in libsupc++ code the red zone
would get corrupted. This was causing random panics, particularly under
heavy system load. Therefore, on x86_64 a separate build of libsupc++
with -mno-red-zone is now done for the kernel to use. Note: this commit
will require a rerun of configure and rebuild of cross tools.

use system zlib when cross building gcc4 to fix #8242

* this add a dependency on package zlib1g-dev for Linux systems.

Fixed a compilation failure for the x86_64 toolchain.

This appears to be a problem with GCC's build system: it defaults to having
multilib enabled, but if it is explicitly enabled with --enable-multilib,
the build fails.

Signed-off-by: Ingo Weinhold <ingo_weinhold@gmx.de>

Added workarounds and options for gcc 4.6.2

* add -Wno-unused-but-set-variable for gcc 4.6.x with a TODO
* fix warnings about wrong size of pointer cast in ioapic.cpp and AudioBuffer.cpp

Closing #8063:
* touch all .info files before trying to build the gcc4
buildtools in order to avoid the dependency on makeinfo.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43012 a95241bf-73f2-0310-859d-f6bbb57e9c96

Replace the $(...) syntax with backticks instead.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41721 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Nathan Mentley: Build the x86-64 build tools with multilib support.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37522 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced new header directory "config", which ATM contains HaikuConfig.h
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

* Added -j<n> option to configure. It is passed to the
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

Don't know why multilib was disabled in r29035, but we'll likely need it for arm, and m68k as well...
Make it depend on haikuMachine.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32213 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Alexander von Gluck (kallisti5) to get the PPC build going again
(mostly at least). Also disables -Werror for the binutils, but those should
be fixed eventually.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29804 a95241bf-73f2-0310-859d-f6bbb57e9c96

Forgot to update this reference when renaming be/ to os/.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29069 a95241bf-73f2-0310-859d-f6bbb57e9c96

The default include paths have been updated from be/ to os/ so copy correspondingly.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29057 a95241bf-73f2-0310-859d-f6bbb57e9c96

Updating config for current GCC4 cross compiler.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29035 a95241bf-73f2-0310-859d-f6bbb57e9c96

- Have OpenBSD use gmake
- export MAKE to make sure submakes use it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28250 a95241bf-73f2-0310-859d-f6bbb57e9c96

gcc 4.1.2 conveniently saves the version number in a separate file.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20319 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added shebang. Should fix bug #956.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20062 a95241bf-73f2-0310-859d-f6bbb57e9c96

* reverted changes of revision 18985, as Ingo has pointed out, they were useless.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18994 a95241bf-73f2-0310-859d-f6bbb57e9c96

* implemented a suggestion of korli: the legacy & gcc4 cross-tools are now built
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

Adjusted build_cross_tools_gcc4 and configure to be able to build PPC
build tools as well. The configure option --build-cross-tools-gcc4 has a
new parameter to specify the architecture.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15382 a95241bf-73f2-0310-859d-f6bbb57e9c96

When building the gcc 4 cross tools we now configure for machine
i586-pc-haiku.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15345 a95241bf-73f2-0310-859d-f6bbb57e9c96

Adjusted build_cross_tools[_gcc4] scripts according to the new directory
layout in the buildtools module.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15083 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moved FreeBSD setup to define a freebsd build platform. GCC4 apparently also requires the use of GNU Make, so told the build_cross_tools script to use 'gmake' instead of 'make' on BSD systems.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15024 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added build_cross_tools_gcc4 script which builds gcc 4 and binutils
from the sources. Added respective configure option
--build-cross-tools-gcc4.
* Fixed running "configure --build-cross-tools" from another directory
than the source dir. The parameter to the script was missing and thus
the tools were created in <sources>/generated.
* Removed stdc++ lib header dir ".../debug". One is supposed to include
<debug/...> to get the debug headers.
* The stdc++ lib header dirs are now listed one per line in the
generated BuildConfig. This works around the 512 bytes jam line length
limit.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15020 a95241bf-73f2-0310-859d-f6bbb57e9c96