Move host platform detection up, fix indentation.
If the host platform is a BSD (darwin|freebsd|openbsd) use stat -f,
otherwise use stat -c to check for a restrictive umask.
Change-Id: Ifb57eb69153221a23a84700445ff08a96517844a
Reviewed-on: https://review.haiku-os.org/c/1535
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* I added this early on, but to be honest, any interesting
workstation class hardware would be riscv64.
* Since riscv32 is mostly embedded or low power, just drop.
Change-Id: Id36274c882c46e766268f2ab53eb1bd5f95227be
Reviewed-on: https://review.haiku-os.org/c/1352
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: Ic6cfdd2a94c8d6c0a7f4963fe892f8dc73e97afd
Reviewed-on: https://review.haiku-os.org/c/1323
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Some operating systems only ship with Python 3 and the
binary for this is 'python3' instead of 'python' which
causes the Jam build process to fail because it expects
to find 'python'. This change will mean that the
configure process will detect this case and configure
the build to use the correct binary name.
Fixes #14938
Change-Id: I30cd0df828792715a54d760b86dd79aee04e2b2f
Reviewed-on: https://review.haiku-os.org/c/1134
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Gets the stage0 bootstrap to run.
Imlementation is probably nonsense at this point.
Change-Id: I10876efbb54314b864c0ad951152757cdb2fd366
Reviewed-on: https://review.haiku-os.org/c/1061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Now that HAIKU_TOP is a relative path, nearly all paths Jam actually
has to deal with will never contain spaces, so this is now feasible.
Only one issue remains after this commit (namely, setting
HOST_BUILD_COMPATIBILITY_LIB_DIR.)
This doesn't fully work yet (the FS code in libroot_build
needs to be adapted, as some of the symlink-related calls
are not available on MinGW), but it gets much further than
the "Cygwin" target did.
These have been broken for a long time. Some Cygwin changes that
are relevant on MinGW are kept here, but users on Windows who
want to build Haiku should probably use WSL at this point.
However, now that we are using relative paths and don't need
to worry about drive path kludges, it's actually possible to
get some host tools built on MinGW. Changes for that coming.
This reverts commit da693d1fdc.
GCC2 binutils doesn't like this. As mentioned in the previous commit,
"u" is a no-op on modern binutils and only issues a warning.
Jambase now expects this (and its defaults were changed); and this
is already the default on most systems, so adding this should
silence the "D is now the default mode" warning.
* I mean, qemu 3.0 supports it.
* Nobody get excited, we need all the triplets added to
our gcc buildtools. clang 7.0 seems to be cool with riscv though.
Change-Id: I17728163e4f28a3c16cee482a253364724b06f3a
Prior to hrev47631 (2014), HAIKU_TOP was relative when jam was invoked
from the repository root, and not relative when jam was invoked from
any other location, including "generated." In hrev47631, Jamrules
was changed to be as it was before this commit, in order to fix #11101
(Haiku repository creation failed due to the use of relative paths.)
GCC, however, injects the full path passed to the compiler into some
symbols under certain circumstanes (anonymous namespaces, for one),
and so a relative path for more reproducible builds is preferred.
It seems the aforementioned bug is no longer with us, as a full image
build that I did with this change worked just fine.
Note that you will have to run "configure --update" after this
in the case that you usually invoke "jam" from the generated directory,
as the Jamfile configure generated included absolute paths. (The reminder
to do that this diff includes can be removed after some reasonable amount
of time.)
It seems that the old buildbots had their (ancient) checkouts done with a
restrictive umask, and this meant that some files in buildbot-generated
builds were not readable by "world" as they should have been.
Now instead of just verifying the umask itself is not too restrictive,
we also validate the "SetupEnvironment" script in the tree has mode 644.
Fixes #14085.
We do a lot of checks against the CC specified in environment,
but we never pass it into the BuildConfig, so we have no guarantee
that's what Jam's actually using.
Additionally remove HAIKU_BOOT_BOARD while we're at it (nothing uses
it anymore), and reorder the sections in BuildConfig to make a little
more sense.
The former is passed to the compiler when linking using it,
the latter is passed to ld when it is invoked directly.
Also modify ArchitectureRules to not overwrite this setting.
It will probably be just stubs for the significant future, but,
here it is anyway.
Regarding the naming: Yes, the official name is "aarch64." However,
Linux, FreeBSD, and Zircon all call it "arm64", and so we will do the same.
I've configured it initially to be a Clang-only port, making no
changes to GCC buildtools whatsoever here. We'll see if that sticks,
however.
Previously we initialized variables and ran a few $CC tests first
(which was what the old version of --update needed.) Now, we can do it
almost immediately after the script begins.
Spotted by running --update on a GCCless system (as the $CC tests
gave warning messages due to no GCC, while CC= was set in --update
environs.)
Now, instead of breaking them up, all settings related to or gleaned
from the compiler are listed first (except for BOOT_CXXFLAGS_...).
No functional change intended.
If one specifies a cross-tools path instead of --build-cross-tools along
with --use-clang, then the specified architecture winds up in the list twice,
as the first test looks for the arch name where only "unknown" exists
(since in the case of cross-tools paths, we delay fetching the arch.)
So we need to move this check to there instead.
This lets clang use our linker and other binutils instead of its own.
Now clang builds produce a working bootloader and get all the way
to the "rocket" icon, at which point userland init fails.
* Seeing an issue on our builders where the toolchain directory
exists, but the gcc binaries do not.
* Check for the path, as well as the actual compiler binaries
to improve detection of need to rebuild toolchain.
Change-Id: I54fd5789e3255c8295136bb0614e72c5393718fe
Following recent changes to use libroot_build on Haiku also, it is now
actually impossible to build Haiku components on non-Haiku platforms
(BeOS R5, Dan0, BONE, Zeta), so we can remove any logic related to this.
This is only the first part; still to be removed are:
* SetSubDirSupportedPlatformsBeOSCompatible
* HOST_PLATFORM_BEOS_COMPATIBLE
* TARGET_PLATFORM_BEOS_COMPATIBLE
Implemented by just not defining the functions at all and letting
the Haiku ones shine through. In the future, though, we should wrap
them properly.
(Between the switch to libroot_build and this commit, libroot_build
was using the generic attribute emulation layer on Haiku ... whoops.)
The previous commit only checked that they worked if the user
enabled them, but now they will be enabled automatically if the
underlying filesystem supports them.
The ReadMe.Compiling has been updated accordingly.
Previously the helptext just displayed a warning to "make sure your
file system supports sufficient attribute sizes", and left the
actual checks to libroot_build at runtime.
Now we use the native command-line tools of each platform to make sure
that we can actually set attributes large enough for --use-xattr and
--use-xattr-ref respectively.
Previously --update was kind of a hack, as it just dumped all
the variables from BuildConfig back into ./configure and attempted
to rerun from there.
Instead, now we store all of the variables and environs configure
was invoked with in the top of BuildConfig and re-call it using them.
This is much more robust, as configure will actually recompute
all of the values from the BuildConfig.
As a side effect, if configure was originally invoked to build crosstools,
it would have done so again, so instead add a check to see if they
exist, and skip them if they do. It's easy enough to delete the
directory if you want to force a crosstools rebuild.
Briefly discussed with mmlr on IRC.
When compiling with GCC, these headers get pulled in from the
gcc_syslibs_devel package, but we cannot do something similar
for Clang as Clang adds/removes internal builtins used by
the headers nearly every version. So instead we just copy
all the intrinsics headers from current Clang into generated,
and make sure this directory is included before any others.
* Actually locate the clang executable, and allow user overrides
* Properly preserve arguments in get_build_tool_path
* Fix get_build_tool_path for commands with dashes (e.g. "clang-5.0")
Jaroslaw Pelczar