Change-Id: Ia2a86d8814d06950ea2d2d19d966c642d26f81d6
Reviewed-on: https://review.haiku-os.org/c/1302
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
On x86 and x86_64, this warning is never emitted because it is perfectly
fine to do unaligned access. On sparc, such accesses are not supported
by the hardware and will generate a SIGBUS. This must be caught by a
trap handler, and the unaligned access performed there, slowly, using
byte by byte access.
However, making this a Werror is annoying because it will trigger
everytime one casts a byte pointer to something larger, even when
alignment is actually preserved. So, removing all such warnings would be
nearly impossible (for example, just for the mergesort function, there
is a whole GSoC project for it at FreeBSD).
Keep it as a warning for now. The warning can be silenced by using
BytePointer, if desired. We should also investigate where the SIGBUS
trap is triggered a lot and consider improving the alignment of data
where possible.
Change-Id: I6b90025e8c6d69ef1ccda3c10eee270ccc1ebd29
Reviewed-on: https://review.haiku-os.org/c/1103
Reviewed-by: waddlesplash <waddlesplash@gmail.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>
Use the latest version of the compiler for bootstrap.
Change-Id: I43639b560de2d4f3dc3fed48c3d4bd32a544cb57
Reviewed-on: https://review.haiku-os.org/c/1104
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
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!"
The generic CCFLAGS are already appended to the HAIKU_KERNEL_*FLAGS
and HAIKU_BOOT_*FLAGS, so these were just duplicates. And now that
we strip certain flags out of the base ones, this was incorrect
(and causes Clang to error in some circumstances.)
* Move -fPIC to ccBaseFlags, as we don't want it in ASFLAGS.
* Remove -fPIC from BOOT_CCFLAGS, as we never want it in there.
* Move EFI flags to the actual EFI setup location.
Clang doesn't support -maccumulate-outgoing-args, -nostartfiles
is not needed in LDFLAGS (and lld doesn't know about it anyway),
and Clang uses .dynstr so we need to copy it also.
The paths to tools are relative to cwd, and HAIKU_ABSOLUTE_OUTPUT_DIR is
not necessarily the same as that, in the case where jam is invoked from
the repository root instead of a "generated" directory.
HOST_OBJECT_BASE_DIR is relative to pwd also, so just make it absolute.
Change-Id: I2aef83804be31c3c03c8577d56372f2dc6cb77f8
Reviewed-on: https://review.haiku-os.org/718
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* First re-fix of what was reverted in 85f8e7001
* haikuporter calls these during bootstrap and needs absolute paths
Change-Id: I40f1b15ffd474d3286356f3151eacd9a4a09add2
These data files are used in the generation of build targets,
so moving them to src/data alongside the package_infos & etc.
makes more sense.
They don't seem to be activated properly though (I added some tracing
to try and figure out why they aren't used but haven't gotten to the
bottom of that yet.)
This reverts commit 030d0eb58f.
It is absolutely not correct to assume PWD is the generated dir;
it may also be the repository root.
Fixes jam putting some build artifacts in the source tree.
* 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
* The PWD's are live based on jam run location which means
they shouldn't bind the generated directory to a fixed path
as before.
* We also need an absolute LD_LIBRARY PATH since haikuporter
loses the context invoking host tools.
* I don't think we can run jam from outside of the generated
directory anymore... but I don't think that was a thing.
Change-Id: I020f902ce5235bf268c9075d6e2ae85296a4ad20
* haikuporter's cwd is the haikuporter path during execution
(haikuporter/HaikuPorter)
* We have to pass the full working path and can't use a relative
path here
* Seems to fix the bootstrap build
Change-Id: Ibb139f164c5e08eda3a08136c4e9ea2c9eaeae9e
Strictly POSIX-compliant shells (like dash) do not allow sourcing
files in the present directory without "./". The script really should
not know or care about what directory the passed files are in,
so now we add a jam grist to make the passed paths absolute.
Fixes the build on all systems where /bin/sh is dash or a similarly
POSIX-compliant-no-extensions shell (i.e. virtually all Linux.)
Curerntly contains support for amiga RDB and Apple (PPC) partitionning systems,
that is, things that might be useful, but not for most users, and was
not part of the default package.
Naming inspired from the Extras disk shipped with Amiga Workbench, for
lack of a better idea.
Change-Id: I57fb229806139939bc019e6c43b0aec7ea1f483a
Reviewed-on: https://review.haiku-os.org/652
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* We're making the assumption about EFI here, but it's
fine since those defines will just go unused on non-efi builds.
* Jam segfaults when we get two for's, a case, and an if deep.
(adding an x86_64 check to efi section just below)
Change-Id: Id98e87b6570ddc7d9c2195cd05b0526e71771675
* Move MMU image to a real image define vs being crammed into
the u-boot bootloader Jamfile
* ARM not working yet, but better!
* x86 still builds
Change-Id: I3fb873dbac06fe2db893915b667bf3ce1df44686
Previously only the "effective revision", i.e. the hrev by itself,
was used. Now we include the "commits ahead" count and the "dirty" flag,
if they're there, using _ instead of - of course.
Change-Id: I5238d01926c2cca242bffbdef30bff606a173a06
Reviewed-on: https://review.haiku-os.org/596
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit e7c5d994267fb7d49e3dd50c2854e9b37c9ffca1)
Reviewed-on: https://review.haiku-os.org/597
We don't want to ship these images as the ones for main distribution,
but at least we can make them available as downloads for those who do want
to use CDs.
* This gives us plenty of space for source packages.
* A Mini-DVD is 1.4 GiB, and USB sticks of 2 GiB are at
the sweet spot of low-price vs size.
* Unused space will be compressed in release zip.
* We blew by 700 MiB long ago. Sorry CD-R folks.
Change-Id: I3bbe4508777027f6fe7c0ee2992637541feeb88f
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>
* PRE_BETA_2 is now the default in master.
* For libbe: R1/alpha4 used internal=8, but nobody bumped master
at the same time, so now we are on internal=9.
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.
The latter is not just a symlink to the former, but is a small pseudo-
library that tells the linker to use the .so.1 version instead. As we
do not pass -L to this directory to the linker invocation, the linker
thus cannot find it, and so errors out.
We rightly do not want the linker doing "magic" things for us that
we don't expect, and so even if this one case is fine, we shouldn't
allow the linker to take care of this automatically for us when
it comes to libroot and other core system functionality, especially
as going forward we may indeed add a second libgcc version due to ABI
breaks. Instead, link against .so.1 directly.
Fixes the build breakage caused by the GCC 7 bump.
We now build libicns against it. It seems that it is better-maintained than
JasPer, so we should probably consider switching the JPEG2000Translator to
use it also.
ffmpeg_devel pulls in some other devel packages we don't really need,
and very few things are built against it anyway, so whoever needs it
can install it manually. Same goes for freetype and fontconfig.
* Store pointers in an addr_t instead of int32, for 64-bit's sake
* Use DebugSupport.h instead of userlandfs Debug.h and remove extra parentheses
* Create a header-only String class based on the userlandfs String and use it
* RecursiveLock instead of Locker.
* Jamfile cleanups and other misc. changes.
It isn't yet adapted to the new VFS API, so the build is still somewhat
broken.
This contains the contents of Haiku's sources, which is necessary
to include in "with source" builds for proper (L)GPL compliance,
mostly because we have GPL code in the tree.
"cpp" is the system C preprocessor, not the one from our cross-compiler,
and in the case of my system which does not have GCC installed at all,
it doesn't even exist.
With this, Clang-ARM builds successfully create a "haiku-arm.mmc".
I couldn't get it to output, even after blessing it with "rune",
but that may just be my fault...
Now that HOST_CC is actually passed in, we need to default
everything to it; otherwise, it's up to the Jambase as to
what CC we are actually using.
Found by trying to build Haiku on a system that has no "cc"
executable, but Jam tried to use it anyway (as all three of CC,
C++, and LINK.)
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.
This rule process the entire target's source files at once, and so
whoever wrote this rule in the first place (PulkoMandy?) probably
assumed without even testing that "cc -E" would create multiple
outputs for multiple inputs.
It doesn't, though: it just outputs them in sequence on the command line
the same way it does when the files are piped in through "cat". This
also has other advantages (e.g. preprocess errors caused by the compiler
assuming it was C not C++ code and so not defining __cplusplus, local
includes are now resolved properly, etc.)
Doing it this way does exposes other problems like the one fixed in the
previous commit (headers with no context defined, which worked previously
only because they used the context of the preceding `cat`'ed file.)
We now also remove the .pre file after collecting the catkeys.
Otherwise, Clang warns that we haven't set an architecture on ARM,
which is set in CCFLAGS. Since these might also contain other flags
that affect the preprocessor, there isn't any good reason to not
pass it through, so do that.
It seems that at on some platforms at least, Clang uses @define instead
of #define, but with functionally identical syntax, so use sed to
process it as such.
We lost these tunings when I moved us away from board focused
builds. I feel like most of our ARM interest is around ARMv7+
Change-Id: Ie301d275a74d48ee3d0c4c7dc7d6cdd635288a7b
This requires a trunk build of Clang (the flag was only implemented
& introduced 12 days ago), but at present, full builds will fail
due to an unrelated Clang bug: https://bugs.llvm.org/show_bug.cgi?id=38356
* __NO_INLINE__ fixes the cross-build on some glibc-based systems with
newer compilers, as it prevents glibc from declaring functions inline
that we override in libroot_build.
* We can now enable tree-vrp as long as no-delete-null-pointer-checks
goes where it used to.
