* The GCC2 buildtool sources were updated, so change the date
* A new GCC2 optional package will be added later today
+alpha 4 (build will break otherwise)
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.
The elfedit tool doesn't exist with the old binutils, so configure was
failing when it tried to get the path to it. Only try to search for it
if building GCC 4.
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
* 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.
* applied patch by VinDuv that adds a Perl-based implementation of readlink,
which is needed on Mac OX X, as that doesn't have any of the other fallbacks
- thanks!
IIRC, other people have managed to configure without this on Mac OS X, but
I suppose no harm can be done by providing this as last resort.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38454 a95241bf-73f2-0310-859d-f6bbb57e9c96
(a version that correctly deals with utf-8 chars in wide character literals)
* adjusted required gcc2 version in configure
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37483 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
* Renamed DownloadFile to DownloadLocatedFile.
* Pulled a generalized rule DownloadFile out of DownloadOptionalPackage.
* Added InstallSourceArchive rule which can be used in OptionalPackages to
add sources for installed packages to the image.
* Added configure option --include-sources to enable including the sources
for third party software in the image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35617 a95241bf-73f2-0310-859d-f6bbb57e9c96
variables in the script and in generated BuildConfig file. Otherwise the
--update option wouldn't correctly pick it up.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35400 a95241bf-73f2-0310-859d-f6bbb57e9c96
doesn't know them. Not sure why that was commented out -- only this way the
build system knows that the libs aren't available. Fixes the non-Haiku build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35397 a95241bf-73f2-0310-859d-f6bbb57e9c96
