* None of these are required to be cross-built, as they all can be built on
the bootstrap image just fine.
* Additionally, update bash_boostrap from 4.27 to 4.30, as 4.27 causes the
build of gcc on the bootstrap image to fail.
* 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.
* Adjust package_repo create command to check if each given package
exists before adding it to the repository writer and fail with
an appropriate message when it does not.
* Partly reverting hrev47655, as the moved declarations are expected
by many ports to be accessable via string.h.
Following standards is a good thing in general, but not if it causes
more problems than it helps ...
* They will be updated by a cron job once per day.
This improves the reproducability of non-current builds, as the ID-files
will no longer change over time.
* Let the jamfile set HAVE_DEFAULT_GEOLOCATION_SERVICE_KEY if the
header that is supposed to contain it is found in src/kits/shared
(which isn't the case for normal builds).
* In case HAVE_DEFAULT_GEOLOCATION_SERVICE_KEY is set, include the
corresponding header and activate Mozilla's geolocation service with
the key defined in that header.
This procedure should enable buildbot to create nightly images without
exposing the private service key.
* With HAIKU_NO_DOWNLOADS=1, the check against existing package files
in the download folder should only be done in the phase that is
adding packages to be put onto the resulting target image, not in the
phase that is adding the bootstrap packages (as here those packages
will be *built*, not downloaded).
* Restore missing definitions of std::nothrow and mynothrow that are
required for the debug build.
* Additionally, cleanup function overrides provided by kernel_cpp,
such that any exceptions in kernel, bootloader or runtime_loader will
trigger a panic.
* The given void pointers are pointers to the actual list items, which
are pointers themselves, so there was an indirection missing
* Fix inverted sort order
This could have caused spurious crashes related to initialization of
the locale kit, most notably this was responsible for triggering a
crashing bug in the plaintext add-on that caused the x86 image
not being able to boot.
I will continue with trying to find the actual crash, too.
* From now on, the gcc-specific system libraries (libgcc, libsupc++ and
libstdc++) are provided by separate packages built along with gcc:
- gcc_syslibs contains the shared libraries (libgcc_s.so, libsupc++.so and
libstdc++.so)
- gcc_syslibs_devel contains the static libraries and both c++ and gcc
headers
The shared libraries now make proper use of symbol versioning and there
are version-specific symlinks
* The buildsystem has been adjusted to no longer use the libraries and
headers from the cross-compiler, but use the ones provided by the
above-mentioned packages. The only exception is that the 32-bit libraries
required for the bootloader of the x86_64 architecture are still taken
from the cross-compiler.
* This stage builds the gcc packages to get the shared syslibs, which
only requires the Haiku glue code.
* Add separate declaration section for stage0 packages to
HaikuPortsCross repository files.
* For the bootstrap_stage0 platform, fall back to the gcc headers
provided by the cross-compiler.
* No longer apply somewhat crude mechanism for converting a package name
into a corresponding port name - haikuporter by now supports package
names directly.
This fixes a problem when trying to pass 'gcc_syslibs_devel' to
haikuporter, which only ever saw 'gcc_syslibs'.
* <stubbed>libroot.so is a shared library which contains all the symbols
from libroot, but without any code. This library will be required by
the (to be introduced) stage0 of the bootstrap process, in order to
be able to link the shared gcc syslibs (libstdc++.so, libsupc++.so
and libgcc_s.so).
* 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).
* The new libstdc++.so contains program headers of type PT_RELRO (for
making segments read-only after relocation). While the actual feature
has not been implemented, the runtime_loader should now silently
accept (and ignore) those program headers.
* Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so
from the gcc_syslibs build feature for everything except x86_gcc2.
* Use libgcc_s.so from the gcc_syslibs build feature for everything but
x86_gcc2 (which still carries libgcc as part of libroot.so).
* Drop filtering of libgcc objects for libroot, as that is no longer
necessary since we're only using libgcc-as-single-object for libroot
with x86_gcc2, where the filtered object file doesn't exist. Should
the objects that used to be filtered cause any problems as part of
libgcc_s.so, we can always filter them as part of the gcc build.
* Use libsupc++.so from the gcc_syslibs build feature for everything but
x86_gcc2.
* Adjust all Jamfiles accordingly.
* Deactivate building of faked libstdc++.so for non-x86-gcc2. For
x86_gcc2, we still build libstdc++.so from the sources in the Haiku
source tree as part of the Haiku build .
* Put gcc_syslibs package onto the image, when needed.
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.
* Invoking jam from Haiku's checkout directory (instead of the output
directory) caused the repository creation to fail because of relative
paths to package files being used. Now we make sure that HAIKU_TOP
is an absolute path to avoid problems like these.
* 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.
* This file contains jam rules for getting the different versions
of libgcc, libsupc++ and libstdc++ used throughout Haiku's
build system.
* Additionally, there are rules for accessing the c++ headers
and the gcc headers.
* These rules are included by Jamrules, but not yet used anywhere.
* gcc_syslibs contains the shared libraries that are being built
as part of gcc, i.e. libgcc_s.so, libsupc++.so and libstdc++.so
* gcc_syslibs_devel contains the static versions of the respective
libraries plus additionally kernel versions of libgcc.a and
libsupc++.a (which do not provide support for pthreads or TLS
and thus do not have any external dependencies). Additionally,
this build feature contains the c++ and gcc headers from the
non-legacy compiler.
* When adjusting the package name for the secondary architecture,
it is unclear where exactly in the package name the architecture
specifier is. To remedy, we try all possible positions until
we find the package (or there are no other possibilities).
* Haiku does not currently provide crtbeginS.o and crtendS.o, so
we fall back to crtbegin.o and crtend.o.
This should not have any ill-effects, as the available compilers on
Haiku do not use __cxa_atexit() yet.
* Gcc is now using __cxa_atexit, so we need to use the crtbegin
and crtend implementations that are meant to be used for shared
libraries. This avoids crashes of servers that load add-ons
(Media-Addon-Server and Print-Server) when shutting down Haiku.
* As executable are shared on Haiku, we use crtbeginS.o and crtendS.o
for those, too.
* To simplify, we even use crtbeginS.o and crtendS.o in the kernel,
but there they don't currently make a difference, as the respective
initialization and cleanup functions are not being invoked by the
kernel.
* Now that system updates seem to work properly, put the haiku
repository config and cache file onto the image automatically.
* Adjust URL of haiku repository (it is currently redirected
to some other URL at download.haiku-os.org, but that will be
changed later).
* 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.
* To avoid problems caused by the varying python versions used by the
different architectures, switch those packages from 'any' to explicit
architecture.
* That change did not make any sense, as the floppy-boot images
can't be built in debug mode anyway (the result is much too large).
This reverts commit 911821275a.
* Adjust the respective rules such that with disabled downloads, only
packages already available in the downloads folder will be considered
as available build features.
This way, the build system will not for instance try to build
<kdebug>qrencode after a bootstrap, as that package is not yet
available.
* If --no-downloads has been given, Haiku will be built without
trying to download anything, all required packages need to be put
into the download folder manually (the build will stop on missing
packages).
* As the required HaikuPorts repository can't be downloaded in this
mode, a local repository is created during the build, which only
contains the packages available in the downloads folder.
This is useful for building Haiku completely from source.
* The content of the preprocessed package-info files and the package
contents depend on the build type, so we use a different folder for
each build type.
* Instead of forcing the hash-table to use a copy of the key,
introduce and use TypeOperation template to avoid taking a
reference of a reference type (which gcc2 doesn't allow).
* Instead of separate variables, HAIKU_BUILD_TYPE is set to one of
'bootstrap', 'minimum' or 'regular'.
* Adjust uses of HAIKU_BOOTSTRAP_BUILD accordingly.
* Introduce a build feature per image type (i.e. minimum_image,
bootstrap_image and regular_image).
* Activate the build feature matching the active image type.
* Use the image build features to group the default packages.
* Move actual definitions of respective image contents to files
underneath build/jam/images/definitions (minimum, bootstrap, regular).
* HaikuImage now only includes the image definitions for the selected
build profile and adds the Haiku packages.
* Simplified topmost Jamfile to some extent.
* Move definition of DESKBAR_APPLICATIONS and DESKBAR_DESKTOP_APPLETS
from build/jam/packages/Haiku to the respective image definition file.
* Sort and reformat several lists to make them more readable.
* Add new build profile 'minimum', which defines a minimum set of
packages.
* Introduce HAIKU_BOOTSTRAP_SOURCES_PROFILE and let it default to
'@minimum-raw'. This can be overruled in UserBuildConfig, setting
it to '@release-raw' will cause all source packages required for a
full release to be put onto the bootstrap-image.
* Add new image HaikuImageMinimum, which is meant to define the minimum
useful Haiku image (yeah, I know that's vague).
* Add HAIKU_MINIMUM_BUILD, which indicates that HaikuImageMinimum should
be used (it would be better to merge this with HAIKU_BOOTSTRAP_BUILD
into something like HAIKU_BUILD_TYPE)
* Cleanup duplicate references to basic packages - those are now added
by the topmost Jamfile (no longer referenced by the build profiles).
* This decouples the versions referenced by the architecture-specific
repository file from the actual versions available in the haikuports
branch that happens to be used for the bootstrap build.
* Before, we were putting both rigged and standard source packages
onto the bootstrap image, which caused the build to fail (because
non-rigged source packages can only be built with git available).
* Libbe is not available when cross-building the *_bootstrap packages,
so no libnetwork could not be used either, which made building
anything network-related impossible.
* The only code in libnetwork that requires libbe is the notification,
so I moved that over to libbnetapi. Non-C++ applications can't use
the notification calls anyway, as their interface is C++-only.
* as Ingo has pointed out, the remote user settings doesn't
relate to the build configuration at all, so setting the
remote user via HAIKU_REMOTE_USER in UserBuildConfig or
via shell environment is the way to go
* additionally: drop debug output
Oliver Tappe