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")
No longer used by anything (it appears some old kernel drivers that
are not included in the build might use it, but I don't know why
they need it -- we already ship GPL'd code [libntfs] for the kernel
in the default build unconditionally.)
Briefly discussed with js a few weeks back.
* Eventually BoardSetups and target boards will go away.
* Include all known fdt's in the mmc image
* This gets us closer to target board-less arm
* Changing hardware is as simple as plugging a new fdt
into u-boot's startup script.
* Drop my original rpi1 work. We're targetting ARMv7
minimum.
* beaglebone vs beagleboard
* While the boards are almost the same, they have
diff. FDT's now (more memory, different layout etc)
* Make u-boot script more rpi-like
(depend on u-boot for initial addresses)
* Wasn't working, still doesn't.
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.
This was added in hrev47174 but isn't needed. (confirmed with jessicah)
the -e flag was causing the script to exit when it encountered an error
instead of allowing us to print an error message and exit ourselves.
I accidentially tried to compile Haiku on a case-insensitive FS and
tripped over this.
The configure script should print an error message if you try to configure
on a case-insensitive FS once again.
