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.
* Create rules (build/jam/PackageRules) and a script,
build_haiku_package, to build hpkg files.
* Move all rule invocations that copy files and created symlinks and
directories in the "system" directory from HaikuImage to
HaikuPackages, which creates a package "haiku.hpkg".
* build_haiku_image: Comment out adding the copyrights info to
AboutSystem for the moment.
* 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__.
* libbe_build: Where possible we directly use the actual Haiku headers and
sources, now. In the headers/build headers we just include the respective
Haiku headers as needed. That still allows overrides where necessary. The
intention is to make it easier to keep the build stuff in sync.
* Fixed a few printf() format and signed/unsigned comparison warnings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42179 a95241bf-73f2-0310-859d-f6bbb57e9c96
Note we aren't yet at the point where jam can make you a floppy image due to broken vm stuff.
It might be interesting to also switch the extension used on the image, amiga emulators prefer .adf for ex.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39165 a95241bf-73f2-0310-859d-f6bbb57e9c96
* make BDADDR_* macros refer to value types instead of addresses
* adjust all interfaces using bdaddr_t* to use (mostly const) refs instead,
which IMHO makes the interface & code clearer
* that got rid of a couple of const incorrectness casts
* some cleanup along the way
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38265 a95241bf-73f2-0310-859d-f6bbb57e9c96
constants, which had to be defined in several places in order to be available
in the kernel addons, network protocols and the server/kit.
* enable -Werror for all servers
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38213 a95241bf-73f2-0310-859d-f6bbb57e9c96
to SetBaseFont() (and fFont to fBaseFont)
* enabled -Werror for all preflets
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38203 a95241bf-73f2-0310-859d-f6bbb57e9c96
state of things for all preflets to the EnableWerror
declarations
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37814 a95241bf-73f2-0310-859d-f6bbb57e9c96
warnings and incorporate some of the ICU-patches we had in our repo before
we upgraded to 4.4.1
* fixed remaining warnings when building locale kit
* activated EnableWerror for locale kit
* added 'Unicode' license, which is the second license in use by ICU
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37763 a95241bf-73f2-0310-859d-f6bbb57e9c96
files from HaikuImage and is set when HAIKU_DISTRO_COMPATIBILITY is 'official'
or 'compatible'
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37742 a95241bf-73f2-0310-859d-f6bbb57e9c96
Haiku causes the image file to need 193 MB; building it in FreeBSD requires
only 180 MB.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37343 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Applications don't have to declare BCatalog fCatalog themselves, it's now done automatically
* Libs and add-ons can be localized just the same way (except static libraries)
For now this new system is yet disabled as I'm looking for some peer review before going on. To enable it you have to define B_TRANSLATE_USE_NEW_MACROS in each file doing catalog access. This will not stay, I'll update the
other apps to use it.
The linking in jamfiles must be not only with liblocale.so, but also liblocalestub.a. Not sure how to handle this for user-side applications. Libraries are also required to provide a MIME signature to use any catalog.
The locale preflet is updated to the new system (as a test). Othe rapps will follow if everyone is ok with this approach.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37323 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added a few header files in headers/posix/arch that'll allow for an x86_64
haiku target to be compiled. fenv.h is src/lib/msun/amd64/fenv.h from
freebsd.
* configure: Added support for x86_64 arch when running
build_cross_tools_gcc4.
* config[_build]/HaikuConfig.h, BuildSetup: Added x86_64 recognition.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36794 a95241bf-73f2-0310-859d-f6bbb57e9c96
