Previously, all packages on the image, both activated and unactivated,
were in $systemPackages, so if a package actually in /system/packages
had a dependency in the Installer optional package area, the dependency
checking would see no problem but the generated image would be broken.
Now, packages going into /system/packages are treated separately
from those going elsewhere, and error checks added so the above
condition will not occur.
(I ran into this while working on the build-package upgrade
in the following commits.)
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>
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.
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.
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>
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++.
