* Try to keep each renderer designed
the same.
* swrast will build... swpipe won't
build until we have an llvm build
package. (should in a few days once
llvm 3.2 is released)
* libmesa and libgallium no longer live in libGL
* opengl kit gets libglapi for dispatch
* swrast will get libmesa
* swpipe will get libmesagallium + gallium drivers + llvm
Work I did at Begeistert, trying to use the new driver manager and
detecting display controls. It should probably be a good example of
how a new driver is built. It currently loads and detects
display controls correctly but doesn't do any actual work yet.
Not sure when I have the time to finish the driver, it shouldn't be
that hard but I currently have have other priorities. Feel free to
work on it in the meantime.
Got rid of X86_ONLY and friends in HaikuImage, FloppyBootImage, etc.
Instead we use build feature specification annotated lists with
FFilterByBuildFeatures (either explicitly or implicitly where passing
the list directly to the image rules).
I just translated the variables to the respective annotatation in most
cases, though in some cases different annotation would be more correct
(e.g. for the OpenGL stuff).
Provides a simple framework for addressing #3798. The interested reader
may add the build features and add/adjust the annotations accordingly.
An archive (ramfs) to be loaded can be specified in the raspberry pi
config.txt with a certain base address. We can use this to put our
floppy boot archive into memory on startup.
During the start procedure we now map that archive so we can later
load the kernel from it.
* As of Mesa3D 9.0+, GLU is a seperate project
* Our in-tree GLUT builds with GLU-9.0 without
modification.
* We ignore the GLU libraries that Mesa-7.8.2 and
Mesa-8.1-devel provide and use the glu-9.0 ones
* This is kind of a limbo state, but works for now.
* Eventually we will be on Mesa 9.0 (which requires
the external GLU) and Mesa 7.8.2 (which works with
the newer external GLU) and will rip GLU out of the
7.8.2 OptionalBuildPackage.
* I don't *think* we are using the Mesa GLU headers...
we will know for sure when I pull'em out of the
OptionalBuildPackages :D
Currently hardcoded to Verdex target. Code prepared to pick up configuration
details from FDT when implemented. Only enabled in FloppyImage for ARM.
This actually enables the kernel to read the content of the image file
passed using the "-pflash" parameter to QEMU....
* Fixed issue with unwanted keymap switching in case UnZip started in
* background (expanding optional packages during Haiku build, for
* example). UnZip executable has no background application flag
* for unknown reason.
+alpha4
Introduce HAIKU_DOWNLOAD_CACHE variable that can point to a directory.
containing optional packages to check first before downloading.
Missing packages are also added to the cache.
This allows sharing and reusing them to make builds without a connection.
* Puri wouldn't work after the update to libpng 1.5
* It was still looking for libpng.so.1.4
* Not intended for r1alpha4 branch, as it's still on libpng 1.4
* These were updated again due to recent changes to the buildtools
* Packages are based on btrev43045, whereas the previous set was based on btrev43040
+alpha 4 (GCC2 package needed to match recent date versioning change to configure script)
* This package is current as of btrev43040
* Primarily did this rebuild to assure the GCC4 package was made with the latest buildtool sources
* This invalidates the need to cherry pick hrev44704 for R1A4
+alpha4
* This package is smaller in size than the previous due to the fix in btrev43038
* This package addresses issue building code with SSP due to fix in btrev43039
* This commit along with btrev43039 fixes#8931
+alpha4 (and hopefully last update to GCC before R1A4 release)
Setting 'HAIKU_STRIP_DEBUG_FROM_OPTIONAL_PACKAGES = 1' will enable the
mechanism. By default all packages will be stripped. Passing anything
other than '1' or 'true' in the InstallOptionalHaikuImagePackage call
will disable it for a particular package.
* added optional feature package for libpng 1.5.12 gcc4/gcc2 x86 and ppc
* drop libpng sources and headers from the tree.
* added optional feature package for jpeg 8d gcc4/gcc2 x86 and ppc
* drop jpeg sources and headers from the tree.
The original package was cross-compiled to Haiku, turns out flex's
build system uses paths to stuff from the host system, so the package
was broken. Rebuilt from Haiku.
Added autoconf, automake, libtool, texinfo, perl, gettext and nano.
Building an image with the nightly targets should give you an image
with these included.
This adds some of the development packages for x86_64. All of the
DevelopmentBase packages (gcc, make, jam, bison, flex, m4, mkdepend)
have been built and uploaded.
* made private Catalog.h header public by moving it to
os/locale/tools/CollectingCatalog.h
* reintroduce B_COLLECTING_CATKEYS define (which is expected to be set
during a collectcatkeys session) in order to decide whether or not
to automatically include the CollecingCatalog.h header from Catalog.h
* adjust jam rule for collecting catalog keys accordingly
Turns out that libgcc is needed, for some reason building the kernel
with -O0 does not end up referencing libgcc but -O2 does. A separate
build of it is done with -mno-red-zone, same reason as for libsupc++.
Ended up being easy to rebuild with different CFLAGS: previously I'd
tried doing `CFLAGS="-mno-red-zone" make` in the libgcc dir which
didn't override, the correct way is `make CFLAGS="-mno-red-zone"`
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.
This reverts commit 14b654326d.
Unfortunately that changeset causes a regression on GCC 2, which
makes playback of (some?) video impossible. This is due to Libavcodec
being miscompiled, which requires gcc >= 4.2
Resolves the regression of #8856, but does not fix the root issue.
* Various compilation fixes.
* Fixes to the FreeBSD compatibility layer (from comparing the x86-
specific bits with the equivalent amd64 sources in FreeBSD).
* Compile all the Ethernet drivers except for sis900 and wb840, these
require a bit more work to fix (will file a ticket soon). Tested
ipro1000 and rtl81xx, no issues.
Some preference apps, mount_server and AboutSystem. Removed the check
for x86_64 in the boot script, the normal path through the script will
work now. Also removed a temporary hack to workaround AboutSystem not
being there in build_haiku_image.
As mentioned in one of the previous commits, breakpoints don't work
properly yet, and I haven't done much extensive testing yet, but the
basic functionality works.
With this commit, app_server now compiles and runs at boot! Nothing
particularly interesting happens, just the blue background and a mouse
pointer. Remote backends are broken and not compiled in, see #8834.
Note that it won't be possible to build this quite yet, need to get
the FreeType package uploaded.
This module provides an interface for drivers to use to perform calls
to the BIOS (only really for use by graphics drivers which need to use
the VESA BIOS). It uses the x86emu library from X.org which emulates
a real mode x86 CPU. This is necessary for x86_64 as virtual 8086 mode
no longer exists there.
* This puts the registers in a better state and ensures
all model dependant defines are prefixed with card series
* Consolidate evergreen defines into single header
The boot script now launches consoled instead if app_server does not
exist, so there is now an interactive Bash prompt! libbe requires ICU,
which is an optional package, so I've built the packages and they've
been uploaded to haiku-files.org (thanks umccullough).
GCC 2 built for OS X 10.7/10.8 was broken, the Haiku build would fail
with some strange errors. Forcing compilation of GCC 2 in 32-bit mode
results in a working GCC.
* Added x86_64 linker script and relocation code.
* Some 64-bit safety fixes to the heap code.
* Added runtime_loader, libroot and bash to the x86_64 image. The boot
script will be launched, but will panic shortly after because fork
is broken.
Added a temporary Haiku64Image file that gets included instead of
HaikuImage when building for x86_64, which I will add to as I port
stuff. Images currently only include the boot loader, kernel and
a bunch of add-ons.
This adds disk drivers, intel/session partitioning systems, and ISO9660
(+ write/attribute_overlay) modules to the CD/floppy boot image targets
for x86_64. The kernel now detects and mounts the boot CD, and runs up
to attempting to start the boot script.
Uses the x86 architecture code, made fixes to printf formats and a
couple of 64-bit fixes. Only potentially intrusive change is that I've
changed PCI.h to use uint32 rather than ulong. I don't see any way
this would cause any issues, though.
- The cdrecord port was using the wrong path for searching for SCSI
devices. This led to it failing to find SATA CD drives. Updated
package by Chris Roberts.
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.
* Add WebKit optional package.
* Make WebKit a dependency of WebPositive
* Enable building of WebPositive from source.
Note: WebKit currently expands to lib/. Alternative gcc-subdirectories
are not taken into consideration. Though it is trivial to change.
* 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).
* set_haiku_revision doesn't currently support ELF64, don't use a
revisioned kernel image on x86_64 for now.
* Don't try to build add-ons for x86_64 yet.
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.
* our current gcc can't be built with multilib for ppc anyway,
* this allows going further on real hardware, though dprintf() sends wrong data to the serial port.
* 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.
* since we include BoardSetup earlier now, the TARGET_* flags were discarded. Use HAIKU_* instead.
* Add variables to hold the default entry point and the desired uimage OS emulation.
* Pi firmware was updated to note that Broadcom
had to be included with firmware blobs.
* While we have permission from Eben to have the
blobs in-tree, they are now offically on github
in a fixed location removing the need to have
these in-tree.
* Clean up BoardConfig, note firmware URL and
files needed
* Update info.txt with how Haiku boot process works
* while it seemed to work before, BuildSetup was actually adding includes from the default boot platform, before BoardSetup had a chance of changing it.
* Thanks go out to Simon Arlott for replacing
the first32k.bin blob with assembly removing
the need for first32k.bin hack.
* This assembly is a modified version removing
the Linux kernel boot args.
* haiku_loader renamed to kernel.img will boot
on Raspberry Pi directly.
* move versions of the B_TRANSLATE_...-macros used during collecting
of catalog keys to a specific header file, which will only be picked
up when running collectcatkeys
* fix a couple of build problems during the preprocessing of the libbe-
sources when extracting catalog keys, all due to private headers not
being found
* move ZombieReplicantView.h from kits/interface to
headers/private/interface, as this way it can be picked up when
building the libbe catalog
* Rename 3D Rendering to GL Info
* Moved it in the source tree from src/preferences/3drendering/
to src/tests/kits/opengl/glinfo/
* Moved in HaikuImage from SYSTEM_PREFERENCES to SYSTEM_APPS
* Does not show up in DESKBAR_APPLICATIONS like AboutSystem
but can be found in the resulting image in /boot/system/apps/
This appears to be a problem with GCC's build system: it defaults to having
multilib enabled, but if it is explicitly enabled with --enable-multilib,
the build fails.
Signed-off-by: Ingo Weinhold <ingo_weinhold@gmx.de>
* 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.
* as pointed out by diver: libgutenberg has been configured to
expect its data files in /system/data, but we used to install them
into common.
This way, the Gutenberg printer add-on actually shows some printers.
