* When --host-only is used, HAIKU_*ARCH is undefined.
* Various architecture variables are undefined resulting
in architecture dependant code paths getting called
recursively.
(blah/Jamfile loads blah//Jamfile vs blah/x86/Jamfile)
* Another option is setting HAIKU_*ARCH to the host arch
if undefined, but that might have unintended impacts.
* Re ML discussions, this should make a lot more
sense to users as it is inline with what most
linux distros ship.
* This will require a tweak to the buildbot.
* First step to shipping anyboot instead of plain iso.
* Only set HAIKU_BOOT_PLATFORM to bios_ia32 if not defined
* Add gnuefi build feature
* Introduce BOOT_LDFLAGS, and move options for passing to linker
into ArchitectureSetup
* x86_64 compile fixes for warnings in boot loader
* loader/elf.cpp: don't include ELF32 support when targeting EFI
* relocation_func.cpp: copy of the relocation code from gnuefi
to make _relocate extern "C", and avoid including <efilib.h>
* boot_loader_efi.ld: copy of gnuefi's elf_x86_64_efi.lds,
modified to include support for C++ constructors, etc. Keep in
sync with the gnuefi package
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Fixes#12710.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
I fixed the modifications to the Jamfiles in src/bin, they were all wrong
in the patch.
* Previous enablement broke gcc2 and hybrid builds
* gcc2 builds fixed and tested working now
* Fix Hybrid builds via missing MultiArch Jam
* Sorry for the noise, enjoy early Bluetooth support
* Add support for macports lib and headers dirs.
* Link libs change for Mac OS X for tool build.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
* 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).
provided in the gcc_syslibs_devel build feature for building Haiku.
* Simplify declaration of c++ and gcc headers for the legacy compiler -
in the end we always use the ones living by our source tree anyway.
* Fix a couple of missing local declarations for jam variables, which
were necessary to avoid a build problem with strace. There are
probably more bugs like these hiding in our build system files, but
I'm saving the fix for those to the next commit.
* Add new gcc packages to the HaikuPorts (x86*-)repositories.
* The main build rules now cause their targets to depend on the
platform such that global per-platform intializations can be
set up by making the platform pseudo target depend on the
target returned by the initialization rule.
* Cleanup the SD card image building to allow jam -q @bootstrap-mmc to
work.
There are a few remaining tricks before you can safely build an image:
* This uses a non-POSIX du option, and is only tested with Linux du
only (Linux is the only supported system to run bootstrap builds,
anyway)
* The Python recipe in haikuports.cross is known to not build on
Debian/Ubuntu, but work fine on OpenSuse. There is a patch available in
haikuports bugtracker to allow the reverse.
* You need to populate the haikuports repo package list with some
packages (which don't exist yet) to make the build system happy. But our
git hook to generate the repositories is preventnig me to share this
hack.
Once built, the image currently crashes early in the kernel execution.
On to debug that!
* As per the ML discussions. Bumps MIPS to tier 3.
* We've reached a unanimous descision that MIPS doesn't
target any real / valid hardware Haiku wants to pursue
at the moment. In the event that anyone wants to pursue
MIPS, feel free to fork Haiku into your own repository
(and we'll even link to it on the website ports page)
* If someone develops a viable plan for MIPS (and gets the
port working, it can be readded at a later date)
This is required on OS X and other systems which do not have the glibc
extensions for regular expressions (FreeBSD is not one of them as it
already includes gnuregex in /usr). With this there are no hardcoded
non-standard paths for OS X anymore.
regex.c and regex.h are from the official gnuregex 0.12 distribution,
the only modification is that I added __BEGIN_DECLS and __END_DECLS to
regex.h.
The introduction of secondary arch support for kernel files disabled
-Werror for all kernel files, since the -Werror flags were moved from
{CC,C++}FLAGS to TARGET_WARNING_{CC,C++}FLAGS_<arch>, which, however,
was overwritten by the SetupKernel rule. This commit introduces new
global variables {HAIKU,HOST,TARGET}_WERROR_FLAGS[_<arch>], which
contain the additional -Werror flags to be applied for the architecture.
The config variable WARNINGS can be set to "treatAsErrors" to cause
-Werror and {HOST,TARGET}_WERROR_FLAGS[_<arch>] to be appended to the
compilation flags.
Fixes#10280.
Set HAIKU_CONTAINER_SYSTEM_DIR_TOKENS for the Haiku image to "system
non-packaged". All the rules using the variable would put stuff in
directories that will be read-only in the end (and aren't used anymore).
This way they can be used in UserBuildConfig.
This makes it fit again.
We can't reference in BuildSetup a variable set with the other
ones in KernelArchitectureSetup since the rule is invoked later.
Currently only needed for boot floppy on some platforms.
Disabled for now.
Note we do not have a mean of knowing which file is a binary
or not so we just try to strip, and silently continue when
strip fails (like on the kernel settings file).
Also note strip actually replaces the file, which means it looses
both the resources and attributes, which shouldn't be a problem
for the boot floppy drivers archive, but is not wanted for other
images, so it's not usable elsewhere as such. Patch wanted.
Declare a HOST_PTHREAD_LINKFLAGS variable to hold the flags
required to link with pthreads, and use it for the solver addon.
Works on GNU/Linux, please test and fix for other platforms.
* Add rule FSplitPackageName. It splits a package name into port name
and package suffix.
* FSetConditionsHold: Rename to FConditionsHold and replace the set
parameter by a predicate rule parameter, thus adding more flexibility.
* FIsBuildFeatureEnabled: Use the faster check.
* Add rule FQualifiedBuildFeatureName. Given a build feature name, it
prepends the current packaging architecture to yield a qualified
feature name. Is used by the other build feature rules so that the
same build feature can be configured differently for each arch.
* ExtractBuildFeatureArchives: The supplied list is now filtered via
FFilterByBuildFeatures, allowing for build feature conditions in the
list.
* Add rule InitArchitectureBuildFeatures. It is called early for each
configured architecture, setting up some basic build features for it.
"primary" is set for the primary architecture and a "secondary_<arch>"
is set for each secondary architecture.
* BuildFeatures: Add secondary architecture support: Use the correct
paths for libraries and headers (subdir for secondary architecture)
and configure the icu and zlib sources only for the primary
architecture.
* BootstrapPackageRepository: The package lists are now filtered via
FFilterByBuildFeatures, allowing for build feature conditions in the
lists.
* IsPackageAvailable, FetchPackage: Add secondary architecture support.
* HaikuPortsCross/x86_gcc2: Add icu and zlib x86 secondary packages.
The second stage Haiku cross devel package for the secondary
architecture can now be built.
* All packaging architecture dependent variables do now have a
respective suffix and are set up for each configured packaging
architecture, save for the kernel and boot loader variables, which
are still only set up for the primary architecture.
For convenience TARGET_PACKAGING_ARCH, TARGET_ARCH, TARGET_LIBSUPC++,
and TARGET_LIBSTDC++ are set to the respective values for the primary
packaging architecture by default.
* Introduce a set of MultiArch* rules to help with building targets for
multiple packaging architectures. Generally the respective targets are
(additionally) gristed with the packaging architecture. For libraries
the additional grist is usually omitted for the primary architecture
(e.g. libroot.so and <x86>libroot.so for x86_gcc2/x86 hybrid), so that
Jamfiles for targets built only for the primary architecture don't
need to be changed.
* Add multi-arch build support for all targets needed for the stage 1
cross devel package as well as for libbe (untested).
The goal is to do hybrid builds in a single jam (instead of calling a
sub-jam to build parts with the secondary tool chain). This changeset
adds support to configure to prepare multiple tool chains.
configure:
* Merge option --build-cross-tools-gcc4 into --build-cross-tools. The
option does now always require a packaging architecture parameter,
i.e. x86_gcc2 for the legacy tool chain.
* Multiple occurrences of the --build-cross-tools and
--cross-tools-prefix options are allowed. The first one specifies the
primary tool chain, the subsequent ones the secondary tool chains.
* All architecture dependent jam variables are now suffixed with the
name of the packaging architecture. The new HAIKU_PACKAGING_ARCHS
contains the packaging architectures for the prepared tool chains. The
first element is for the primary tool chain.
* No longer generate a separate libgccObjects file. Just put the
respective variable into BuildConfig as well.
build_cross_tools[_gcc4]:
* Replace the <haiku output dir> parameter by a <install dir>
parameter. This allows to create different cross-tools directories.
They are simply suffixed by the packaging architecture.
Jamrules:
* For the moment map the variables for the primary tool chain to the
respective suffix-less variables, so that everything still works as
before.
The next step is to actually support the secondary tool chains in the
jam build system. This will require quite a bit more butchering, though.
The package kit actually requires the files "repo", "repo.info",
"repo.sha256" to be located under the repository base URL, so the
approach to name the repository file "repo-<hash>" doesn't work.
Now there's a directory "<hash>" which contains the files.
This commit moves the computation of the hash and downloading the
repository file from the build_haiku_image script to the jam build
system. The repo.info is also downloaded and a repository config file
is generated.
* Build libsolv and the dependency solver part of the package kit for
the build platform.
* Add build tool get_package_dependencies. Given a list of package files
and a list of repository files it determines the additional packages
that need to be retrieved from the repositories and prints their URLs.
* Add rules to work with external repositories in the build system
(build/jam/RepositoryRules):
- PackageRepository declares an external repository with all its
packages. The URL of the repository file isn't specified. It is
computed from a given base URL and the SHA256 hash of the list of
package files.
- GeneratedRepositoryPackageList generates a file containing the file
names of all packages in a repository.
- IsPackageAvailable returns whether a package is available in any
repository.
- PackageURL returns the URL for a package.
* Declare the HaikuPorts repository for x86_gcc2
(build/jam/repositories/HaikuPorts/x86_gcc2).
* Add rule AddHaikuImagePackages to add a package to the image and rule
IsHaikuImagePackageAdded to determine whether a package has been
added.
* OptionalPackages: Remove all entries that just downloaded and
installed an external package. AddHaikuImagePackages can be used
instead and is used in the remaining entries. Also move the remaining
optional package dependency declarations from
OptionalPackageDependencies here.
* ExtractBuildFeatureArchives: Instead of the URL parameter a package
name must be specified now. This allows to simplify BuildFeatures
significantly, since there's no dealing with URLs anymore. "if" out
the entries that aren't supported yet.
* build_haiku_image: For the packages installed in system and common
resolve their dependencies and download and install them as well.
The new configure option "--use-xattr-ref" enables an xattr assisted
variant of the generic attribute emulation. Instead of using the inode
ID of a node to identify its attribute directory, we use a reasonably
unique random 128 bit number, which we generate and attach as an
attribute to the node. This way, when a node changes its inode ID
(defragmentation?) or the inode ID of a removed node with a left-over
attribute directory is reused, attributes won't get mixed up.
The old method is still used for symlinks (since on Linux only
priviledged users can write attributes on symlinks), but those usually
only have a rather boring BEOS:TYPE attribute, so mix-ups wouldn't be
that problematic anyway.
* add HAIKU_PACKAGING_ARCH, which is set to the target packaging
architecture
* introduce support for generic package infos, which are package infos
that are the same for all architectures, except for the declaration
of the package architecture itself
* move package info files underneath architecture-specific or generic
folder
This means the build tools will no longer be built against the host
platform's libbe, which avoids compatibility problems -- e.g. an
older Haiku host libbe may not have certain features the build tools
require -- and also makes the build behave more similiar on Haiku and
other platforms. The host libroot dependency still remains and is not
easy to get rid of.
Also remove some bits of BeOS/Dano/Zeta build support.
It's sufficient to simply check if the gcc version is 4 or higher since
we enforce the use of the latest ported compiler for the build anyways,
and these multi-level checks would fail in their current state if gcc
moved to e.g. version 5.0.
Kernel mode code on x86_64 needs to be built with -mno-red-zone as
interrupts would corrupt the red zone if it were in use. However, the
kernel is linked with libsupc++, which was not compiled with
-mno-red-zone. If an interrupt occurred in libsupc++ code the red zone
would get corrupted. This was causing random panics, particularly under
heavy system load. Therefore, on x86_64 a separate build of libsupc++
with -mno-red-zone is now done for the kernel to use. Note: this commit
will require a rerun of configure and rebuild of cross tools.
Added the necessary build flags for modules, and added a module (dpc)
to the floppy image for x86_64 builds for testing purposes. The module
gets loaded correctly and its code runs without issue. Only non-trivial
addition is the different method for generating kernel.so, this is
explained in the kernel Jamfile.
* Use gcc and g++ rather than cc and c++, as the latter now point to
clang with recent Xcode versions and compilation of the host tools
fail for various reasons with it.
* Replace the case-sensitive filesystem check with a more basic one,
as diskutil no longer supports the behaviour of getting info for the
volume that any path is on.
* Updated ReadMe with a correct list of prerequisites for OS X.
* GCC 2 builds are still broken due to a strange error that only
occurs with a GCC 2 built on OS X 10.7
Will be merged with the x86 one later on. Requires -fno-omit-frame-pointer on
the kernel build flags, GCC defaults to not generating stack frames on x86_64.
Since x86 and x86_64 share a lot of common code, x86_64 kernel sources/headers
are going to reside under headers/private/kernel/arch/x86 and
src/system/kernel/arch/x86 along with the existing x86 code. This commit
changes the build system to handle this. A new variable, TARGET_KERNEL_ARCH,
has been added. This is the name of the kernel/boot architecture directory
name, set to x86 on both x86 and x86_64. This is now used in all places where
TARGET_ARCH was used to get to kernel arch sources/headers (I've changed
everything necessary as far as I can tell). Kernel won't build for x86_64
at the moment as the sources have not been merged, loader does.
* platform_allocate_elf_region() is removed, it is implemented in platform-
independent code now (ELF*Class::AllocateRegion). For ELF64 it is now
assumed that 64-bit addresses are mapped in the loader's 32-bit address space
as (address - KERNEL_BASE_64BIT + KERNEL_BASE).
* mapped_delta field from preloaded_*_image removed, now handled compile-time
using the ELF*Class::Map method.
* Also link the kernel with -z max-page-size=0x1000, removes the need for
2MB alignment on the data segment (not going to map the kernel with large
pages for the time being).
The red zone is a 128-byte area below the stack pointer specified by the
AMD64 ABI that can be used by leaf functions for their stack frame without
modifying the stack pointer. It is guaranteed not to be modified by signal
handlers. This cannot be used in kernel mode code, as an interrupt handler
could overwrite it, so stop GCC from generating code that uses it.
* x86_64 is using the existing *_ia32 boot platforms.
* Special flags are required when compiling the loader to get GCC to compile
32-bit code. This adds a new set of rules for compiling boot code rather
than using the kernel rules, which compile using the necessary flags.
* Some x86_64 private headers have been stubbed by #include'ing the x86
versions. These will be replaced later.
* while it seemed to work before, BuildSetup was actually adding includes from the default boot platform, before BoardSetup had a chance of changing it.
* Make the locale kit a part of libbe.
* Drop the LocaleBackend kludge used from within libbe (and from
other places, too) in order to access system catalog strings.
This is now done via gSystemCatalog, which is provided and initialized
by libbe.
* Drop all references to liblocale.so from all Jamfiles.
* Add legacy symlink liblocale.so in order to keep optional packages
that rely on it in a working state.
TODO: the documentation hasn't been updated.
* uncomment the building of libroot_build.a again
* add function remapper to HOST_STATIC_LIBROOT
* drop TODO about the function remapper not working with the static
libroot
Ingo: please review - I think this should work, but I'm not so sure
where HOST_STATIC_LIBROOT should be in the list of libraries of its
only user (<build>bfs_fuse): where it is now or right at the end?
As it is now, the resulting binary still contains references to
host-libc-implementations of close() & others, which are triggered by
the other libs (like libfuse.so). If I put HOST_STATIC_LIBROOT right at
the end, those references are gone, though. But which is correct?
This makes opening symlinks work universally in the build system tools.
Two mechanisms have been implemented, both of which don't always work.
The first is remapping via preprocessor macros. This fails where equally
named methods are used (e.g. STL fstream::open()). The other is using
hidden functions in the new libroot_build_function_remapper.a that is
linked into everything that is linked against libroot_build.so. This one
fails for functions that are defined inline in headers (Linux/glibc does
that). Together they seem to cover our build system needs ATM.
As PulkoMandy pointed out on IRC, darwin10 and 11 (10.6 and 10.7) are at least partially 64bit, so
the test only applies there. When darwin12 comes out it'll have to be fixed.
* Resolve TODO: HOST_GCC_BASE_FLAGS should not be included in
HOST_LDFLAGS. Enable adding "-fno-strict-aliasing -fno-tree-vrp"
accordingly.
* Fix handling of HOST_PLATFORM_IS_64_BIT and HAIKU_HOST_USE_32BIT: The
former does now state whether the platform is effectively treated as
64 bit platform, i.e. it actually is 64 bit and the 32 bit mode is
not enforced. HAIKU_HOST_USE_32BIT is now only set when the platform
is actually 64 bit, but 32 bit mode is enforced.
* Map build variables HOST_CPU and HOST_ARCH to x86_64, if it they are
* x86 and
64 bit and define the __x86_64__ C macro instead of __INTEL__ in that
case.
* <OS.h>: Also handle __x86_64__.
* ensure host isn't darwin as Apple doesn't use binutils
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43202 a95241bf-73f2-0310-859d-f6bbb57e9c96
* fix build due to changes in DSO Linking the right way
as per bonefish.
* we may need to check host GCC version here... can't find
when this option was introduced
* fixes#8031
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43191 a95241bf-73f2-0310-859d-f6bbb57e9c96
The flags given to configure are kept and the build just adds its own flags onto these.
Also the kernel flags are also based on the flags given at configure.
I suspect this will be needed for llvm.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43169 a95241bf-73f2-0310-859d-f6bbb57e9c96
A bit out of my comfortzone with, so please tell me if I'm wrong.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42949 a95241bf-73f2-0310-859d-f6bbb57e9c96
This makes opening symlinks work universally in the build system tools.
Two mechanisms have been implemented, both of which don't always work.
The first is remapping via preprocessor macros. This fails where equally
named methods are used (e.g. STL fstream::open()). The other is using
hidden functions in the new libroot_build_function_remapper.a that is
linked into everything that is linked against libroot_build.so. This one
fails for functions that are defined inline in headers (Linux/glibc does
that). Together they seem to cover our build system needs ATM.
* Introduce on-container jam variable HAIKU_CONTAINER_SYSTEM_DIR_TOKENS
containing the directory tokens relative to the container root to
refer to system.
* Use the variable in *ToContainer rules that need to put something in
system.
* AddFilesToContainer: Fix overlooked reference to AddFilesToHaikuImage.
* AddBootModuleSymlinksToContainer: Use relative symlinks. This avoids
special-casing in the boot loader for packagefs.
