Recent linux behaviour (and also copied by BSD) is to preprocess
DTS files with the C preprpocessor to enable sharing constants between
driver implementation and DTS content for more readability.
In order to automate the complete bootstrap build process we need a
mechanism to control the second phase which builds the final packages
on the booted bootstrap Haiku. To avoid additional dependencies
(buildbot slave, ssh, rsh,...) we'd have to cross-build, there's now a
pair of simple python scripts that allows executing commands on a remote
machine. The server script (bootstrap_daemon.py) is added to the
bootstrap image and started automatically during the boot.
Python 2.7.x has *much* better cross-compiling support so that it's now
actually possible to properly cross-compile Python during the bootstrap.
Before, it would just depend a lot on luck and the build host used, now
it even cross-compiles on OS X.
This means it's now possible to build a working bootstrap image on OS X!
:)
More testing shown that it crashes when decoding some videos which
work with 0.10 (mostly h263 and h264). Gcc4 versions does not seem to
have a problem, so we can keep the update at least there (WebKit and
other gcc4 compiled apps will use it).
Note that the changes in the media plugin are not reversed: they are
compatible with both ffmpeg versions.
* After testing the previous fix, I found that Flurry would crash again
because of a stack overflow in Mesa. This new package fixes that other
issue, so Flurry runs again.
* GLife and Gravity are still crashing, however. I'll debug these next.
* Includes updated CLDR with many bugfixes, including updates to tzdata
for upcoming reform of Russian timezones which reintroduces DST
* Also includes some gcc2 fixes which were missing from our previous ICU
port and were identified by running the ICU test suite.
* This is a very useful control, and 3rd-party apps should be able to
use it.
* But, there are planned improvements (making a better model/view
interface) which prevents making it part of the stable API yet.
We get several users on IRC asking for help on how to disable it. It
doesn't even look good, uses a lot of CPU, and we have better (useful)
ways to demonstrate replicants on the desktop. So this demo has no use
anymore.
* We install the headers for many things that are currently in libshared
(BColumnListView, BCalendarView, etc). So it makes sense to also provide
the lib in an "use at your own risk" way. Only the static library is
included, so apps linking against it should continue running on newer
Haiku versions even if the content of the lib changes.
* 3rd party application developers can now make use of those
experimental features without having to copypaste and fork the sources.
* Fontconfig and freetype are now building fine, so let's add correct
packages.
* Our pixman was way too old and cairo didn't want to use it
* itstool is used by gtk_doc, which will come in another commit.
The previous package was broken (would often segfault, prevented
building Haiku cross-tools under x86_64), so update to the latest
version in HaikuPorts.
Signed-off-by: Alex Smith <alex@alex-smith.me.uk>
* I rebuilt all packages that depend directly on python: I hope I
didn't miss anything.
* SVN upgraded to 1.8.10 because I couldn't get 1.6.18 to build. This
required uodating expat, apr and apr_util, and adding serf which
replaces neon for SVN http support.
* Everything seems to be running fine so far.
* 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).
Let the platform mmu_map_physical_memory the initrd region, and
reserve it before calling mmu_init. This removes another hardcoded
address, since e.g. U-Boot gets the address from the uImage file.
Many bugfixes, most importantly a bug was fixed which makes network
downloads go much faster (without waiting for you to wave the mouse over
the window).
Now that the fake packages are in place, it is much easier to build the
MMC image for ARM without the need for a bootstrap build.
This image still does not manage to access the tarfs and load the kernel
modules, but it gets to KDL, at least.
Needed for the test_app_server.
The logic here may need some improvements, but I'm not sure how to find
the right library name in all cases. I fixed at least the x86_gcc2 case
here.
- Revert the change to BuildFeature since the latest version of the zlib
sources package indeed uses the correct "sources" directory.
- Make the fake zlib package for ARM use the same revision number as the
current zlib version (4) so it can use the current version of the source
package instead of some older one.
This fixes the non-bootstrap ARM build.
I'm not sure this is the right fix, the zlib package seems to come with a
"source" (not "sources") folder on both ARM and x86_gcc2 but then I
don't understand how this worked for the x86_gcc2 build before.
The packages are the bootstrap ones, modified with the "unbootstrap"
script. Not recommended for real use, but this should make playing with
the ARM build a bit simpler.
The libsolv package somehow got lost in the process when I converted
those. Anyone with a copy of the libsolv_bootstrap packages in their
arm generated folder is welcome to "unbootstrap" and upload it.
* 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'.
* 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).
* 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.
Parentheses in target names are considered by Jam to mean an archive
member. We have to explicitly use the M selector to keep that part.
Fixes#10378 (certain keymaps missing on image).
Stop-gap solution to make smpeg installable until the separate libstdc++
package is available. Then it will hopefully have a reliable "compat"
version we can depend on.
* Remove unneeded path mashup in curl to find the ca_root_certificates
and use the file in .self/data/ssl. This makes it possible to rename the
package providing ca_root_certificates without everything exploding.
* Use a certificate file in the format cURL expects, not Mozilla source
file in NSS format.
* 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).
Tested against wget, curl, and git, which all were still able
to verify certificates and download from HTTPS sites.
Signed-off-by: Oliver Tappe <zooey@hirschkaefer.de>
* 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).
- acr (needed by mpd)
- dos2unix
- getconf (used by valgrind)
(also used by autoconf to determine ARG_MAX faster than try-and-error)
- getopt (needed by acr)
- html_parser (used by netsurf for its git manifest)
- readline_x86
- srm
It seems curl doesn't like the new ca_root_certificates package.
This breaks git clone and probably other things.
Maybe it has to do with the version string.
Since I can't seem to build a replacement curl, I'm reverting to the previous
ca_root_certificates so at least next nightly still works.
* Add support for hubs in AllocateDevice().
* Prevent page fault in FinishTransfers().
* Set fCapabilityLength
* Correct in BIOS ownership code
* Fix context errors in _InsertEndpointForPipe().
* Update constants according to latest Specification (v1.1)
* Fix SMI code (reference
http://lkml.iu.edu/hypermail/linux/kernel/1204.2/02460.html).
* Fix Memory/Device-Slot leaks.
* Fix area allocation for TRBs.
* Fix for Intel Lynx Point and Panther Point chipsets. Also move init
of xhci before ehci, to switch USB 2.0 ports before the ehci module
discovers them.
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
* There was a version mismatch between HaikuPorts gcc_bootstrap recipe
and build/jam/repositories/HaikuPortsCross/arm which prevented
building @bootstrap-raw for ARM. Thanks Ingo for helping out!
* Ditto for ppc, x86, x86_64.
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
* 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.
This also adds the libtool_cross_generic package to ARM bootstrap,
which seems to be required for building ncurses successfully. I did
not have the time to verify that this is the case for x86_64 too, so
I'm not yet adding it to there (yet).
Since hrev47198 we have ELF-based TLS support in Haiku. When building
gcc with haikuporter, this is detected by the configure script, but when
cross compiling gcc we need to manually enable it, as no runtime check
can be performed to detect the feature.
This should fix#10938 by avoiding the mix of TLS and non-TLS libstdc++.
* 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!
* 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.
libalm.so is used by Stack & Tile as well as for the constraint-based
layout BALMLayout. This also adds libalm.so to the development package;
links it to /boot/system/development/lib.
