It seems that not all Linux distributions ship an EFI-enabled
cdrtools (i.e. mkisofs takes -e option), Arch being one that
does not.
So instead, we now use xorriso universally, which is
as (or more, in most cases) widely available, and supports
emulating mkisofs with the EFI commands universally.
This also has the added benefit that we can drop genisoimage
support altogether.
When HEAD is tagged, the output will be identical to what it was
before (the latest hrev tag and nothing else.) When HEAD is not tagged,
and the most recent tag is further back, we now use a format like this:
hrevXXXXX+N(+dirty)
... where N is the number of commits since hrevXXXXX, and +dirty is added
if the working tree is dirty. This is significantly shorter than the
previous model (as it does not have the Git revision.)
Fixes#14445.
Change-Id: Ide7f66cf0ac1c1f05402afc52b6be3b68b66d6dc
Reviewed-on: https://review.haiku-os.org/566
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
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.
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.
* 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.
Revert "repo rework: Remove stubs; Breaks repo compat."
Revert "repo rework: Remove need for repos to be self-aware"
This reverts commit a2b2f4d642.
This reverts commit 602076ef82.
This reverts commit 5ffaf72c8a.
These changes break the build on Haiku and the ability to create repo
mirrors, for the lack of a replacement for the URL (an UUID was evoked
on the mailing lists, but not implemented).
We are due for a release soon, please don't break the build.
* See #12917 for details.
* Squashed to one commit to make revert easy if we
run into any issues.
* pkgman is now pre-attached to the 'current' repo
version within nightly images so they can be updated
by default.
* This shouldn't impact us keeping older sets of package
versions by commit hash for building older hrevs.
* There are XXX stubs with "Kill me". These will need
to be dropped after users are given sufficent time to
upgrade. We're dropping a previously required field (url)
so making this a slowish roll out.
* Makes the repos a lot less restrictive which should
help PM package building automation be a bit easier.
* Once this stuff smooths out, we'll add UUID's to the
repo definitions for duplicate repo detection.
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.
* Adjust build_haiku_repository script to invoke package_repo without
-C <dir>, as that is not needed and has the unintended side-effect
of rendering relative package paths non-functional.
In order to automate the complete bootstrap build process we need a
mechanism to control the second phase which builds the final packages
on the booted bootstrap Haiku. To avoid additional dependencies
(buildbot slave, ssh, rsh,...) we'd have to cross-build, there's now a
pair of simple python scripts that allows executing commands on a remote
machine. The server script (bootstrap_daemon.py) is added to the
bootstrap image and started automatically during the boot.
* 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).
* 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.
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++.
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.
* 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.
* 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.
* PreprocessPackageInfo rule: Pull out new rule
PreprocessPackageOrRepositoryInfo which does the sed substituation and
optionally the filtering through the C preprocessor.
* HaikuRepository rule: Generate the repository info file (from the
given template). No longer do that in the build_haiku_repository
script.
If for some reason (e.g., a forced rebuild), Buildbot rebuilds the same hrev,
it was possible for the scp command to place the repositoryDir as a subdir
in $arch/$version/, instead of as $arch/version. This should ensure that the
contents of repositoryDir are placed in $arch/$version/.
* Add rule HaikuRepository to build a repository from a repository info
file and a list of package files. It calls a build_haiku_repository
script which does all the work.
* Add target <repository>haiku for building the Haiku package
repository.
It should be built via "jam -q @alpha-raw build <repository>haiku";
the build profile is only needed to activate all build features.
* rule AddPackageFilesToHaikuImage: Add "flags" parameter. The only
supported flag is "nameFromMetaInfo". It causes the packages to be
copied under their canonical file name onto the image.
* Use the new flag for all generated packages save haiku_loader.hpkg.
... before copying the new contents to the image. This caters to the
typical use case of updating an existing Haiku, making manual
intervention to get the new packages activated unnecessary. The downside
is that manually added packages will be removed as well.
* find_directory() and hard-coded paths use /boot/system instead of
/boot/common.
* The build system creates the writable directories in /boot/system
instead of /boot/common.
* The build system no longer installs any packages in /boot/common.
