* 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.
