This went through review too fast, the wrong variable name was used so
the package name was not listed...
Change-Id: I81d4aa57fdb65297ae9f63ebf123d7a6395a99b6
Reviewed-on: https://review.haiku-os.org/c/1109
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
There seems to be a problem with the way we set the gcc_bootstrap
package build to depend on the bootstrap package with haiku headers.
If said package cannot be built (for example some definitions are
missing for a new architecture), we end up passing an empty string as
the package to use to haikuporter.
The error message given by Haikuporter is confusing, and not easy to
investigate. So, intercept the error earlier to save time for the next
person to hit this problem.
Change-Id: I64f326e5cb3bb0d44632864ad38ad10bb88d0c7b
Reviewed-on: https://review.haiku-os.org/c/1082
Reviewed-by: waddlesplash <waddlesplash@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>
It warns when you try to use some standard library functions
without including the system headers, which we don't
care about as we are providing the system headers in the tree.
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.
Let's make the nightly builds consistent in a way that they would always
be recognized by libosinfo (and, consequently, by GNOME Boxes,
virt-manager, virt-install, ...) by explictly using "nightly" instead
of the $(HAIKU_VERSION) when generating nightly builds.
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
Change-Id: I6fc4f15be1e8e9244abf14e75308fc825f37b2e8
Reviewed-on: https://review.haiku-os.org/c/1053
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
The current volume-id is "bootimg", does not matter which version of
haiku nor to which architecture the ISO is targetting.
Having a "too generic" name as volume-id directly affects the ISO's
recognition by libosinfo.
From now on, let's use:
haiku-$(HAIKU_VERSION)-$(TARGET_ARCH)
Which would generate an ISO with volume-id as:
Volume id: haiku-default-r1~beta1-x86_64
Fixes: #14695
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
Change-Id: I25e2f5338403058a363872abd196d698764cc3c1
Reviewed-on: https://review.haiku-os.org/c/1034
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
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 has been unused since 2010, when the usb_port printer transport
was rewritten to use the USBKit.
Change-Id: I224e07fb35cd9696c07b8f22dd51d3c67d92e0a9
Reviewed-on: https://review.haiku-os.org/c/869
Reviewed-by: Adrien Destugues <pulkomandy@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.)
As Jam prints the entire erring command on failure, including this if-test
in the command itself makes the output somewhat difficult to decipher.
So instead we use two separate rules based on whether or not NO_DOWNLOADS
is set or not.
We don't include the wpa_supplicant on the minimum image, so
these aren't very useful (it seems one needs the wpa_supplicant
to connect even to an unsecured network, with our setup.)
Anyone who needs one of these and also has a reason to use the
minimum image can easily add them back via their UserBuildConfig.
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.
FreeBSD 12's net80211 layer contains only 2 small KPI breaks from FreeBSD 11,
so we can upgrade it, apply those 2 changes to the drivers which are affected
(as the changes are in some lesser-used functions), and then upgrade all drivers
one at a time.
FreeBSD 12 has no major changes to the ifnet KPIs that constitute a
source compatibility break, save a single one related to locking
which doesn't really apply to us, and so we don't need to create
a "freebsd12_network" directory to work through the upgrades.
This replaces the old Haiku-native driver that was removed in the last commit.
It should support all the same chips that one did, in addition to the SiS 7014,
and the DP83815 also.
I don't have this hardware, so for anyone who does, please test.
Fixes#1657.
- USB pen drive seems to still work. More extensive testing welcome.
- USB floppies don't work yet, but they don't work anymore with the
current driver, either. I'm still investigating that part.
Fixes#9276
Change-Id: I8aa5ab828ad2ad867d0c187062d6e179372fc2ad
Reviewed-on: https://review.haiku-os.org/747
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
In some LTO-related experiments, it came out empty due to GCC
not generating actual assembly but rather intermediate code,
resulting in various later targets failing with quite literally
thousands of errors.
I added this here so that one could set -Wextra in BuildConfig and
not be bombarded with useless warnings; but it seems that GCC2 chokes
on it instead of ignoring it. Oh well.
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.
We need to force -m32 here, and we also need to tell Clang that we
want to allow relocations in .text.
Clang builds now get to kernel entry, but the bootloader fails to
load the early-boot modules with strange remapping errors, and so
panics with "get boot partitions failed!"
