build/scripts/gcc2: Specify -fcommon as the default changed in gcc10

* gcc10 changed to -fno-common default
* Resolves #16520

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

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>

build_cross_tools: Compile GCC2 as 32-bit everywhere.

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.

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.

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

Use GNU make also for building gcc 2

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

build_cross_tools: use --with-hybrid-secondary when needed

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.

build_cross_tools: make the cross compiler more reuse friendly

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')

Fix build of gcc2 on BSD (with bsdmake)

* apparently, -j1 doesn't work as intended with bsdmake, so we drop
any multiple-job specification from MAKEFLAGS, instead

Explicitly use -j1 when building gcc2

* specifying -j1 guards against potential multi-job arguments in
MAKEFLAGS

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

Worked around broken GCC 2 on OS X hosts.

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.

Avoid warning about missing math.h.

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

Touch c-gperf.h before building legacy gcc.

Fix typo in build_cross_tools.

Fix the gcc bison issue for real

Also touch cp/parse.{c,h}, which apparently are the culprit.

Work around issue with newer bison versions

Touch the source files generated by bison, so that make won't try to
have them updated.

* Document that the haikuRequiredLegacyGCCVersion variable is
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

* oops - removed debug leftover

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

* add explicit check against mismatching version of legacy compiler, avoids
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

Ignore the additional make flags when building gcc 2. Currently those are
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

* 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

* merged 32bit-wchar_t branches of buildtools and haiku back into
the respective trunk

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

As proposed by "augiedoggie" undefine the _FORTIFY_SOURCE macro, which
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

export foo=bar doesn't seem to work with plain sh...


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

Remove use of bashisms since we use #!/bin/sh. This should help supporting solaris.
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

Switched the legacy compiler to the i586-pc-haiku 2.95.3-haiku-080323
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

Define HUGE_VAL in <math.h> conditionally. That's what gcc's fixincludes
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

When building binutils, build without -Werror. This was causing failures on my linux box due to silly warnings in binutils code.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20227 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

* fixed dependency of build_cross_tools on version of legacy compile, this finally fixes
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

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

Added missing shebang. Thanks to Mathew Schofield.


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

Merged changes from branch build_system_redesign at revision 14573.


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

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

Use GNU make also for building gcc 2

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

build_cross_tools: use --with-hybrid-secondary when needed

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.

build_cross_tools: make the cross compiler more reuse friendly

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')

Fix build of gcc2 on BSD (with bsdmake)

* apparently, -j1 doesn't work as intended with bsdmake, so we drop
any multiple-job specification from MAKEFLAGS, instead

Explicitly use -j1 when building gcc2

* specifying -j1 guards against potential multi-job arguments in
MAKEFLAGS

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

Worked around broken GCC 2 on OS X hosts.

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.

Avoid warning about missing math.h.

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

Touch c-gperf.h before building legacy gcc.

Fix typo in build_cross_tools.

Fix the gcc bison issue for real

Also touch cp/parse.{c,h}, which apparently are the culprit.

Work around issue with newer bison versions

Touch the source files generated by bison, so that make won't try to
have them updated.

* Document that the haikuRequiredLegacyGCCVersion variable is
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

* oops - removed debug leftover

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

* add explicit check against mismatching version of legacy compiler, avoids
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

Ignore the additional make flags when building gcc 2. Currently those are
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

* 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

* merged 32bit-wchar_t branches of buildtools and haiku back into
the respective trunk

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

As proposed by "augiedoggie" undefine the _FORTIFY_SOURCE macro, which
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

export foo=bar doesn't seem to work with plain sh...


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

Remove use of bashisms since we use #!/bin/sh. This should help supporting solaris.
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

Switched the legacy compiler to the i586-pc-haiku 2.95.3-haiku-080323
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

Define HUGE_VAL in <math.h> conditionally. That's what gcc's fixincludes
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

When building binutils, build without -Werror. This was causing failures on my linux box due to silly warnings in binutils code.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20227 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

* fixed dependency of build_cross_tools on version of legacy compile, this finally fixes
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

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

Added missing shebang. Thanks to Mathew Schofield.


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

Merged changes from branch build_system_redesign at revision 14573.


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