The new configure option "--use-xattr-ref" enables an xattr assisted
variant of the generic attribute emulation. Instead of using the inode
ID of a node to identify its attribute directory, we use a reasonably
unique random 128 bit number, which we generate and attach as an
attribute to the node. This way, when a node changes its inode ID
(defragmentation?) or the inode ID of a removed node with a left-over
attribute directory is reused, attributes won't get mixed up.
The old method is still used for symlinks (since on Linux only
priviledged users can write attributes on symlinks), but those usually
only have a rather boring BEOS:TYPE attribute, so mix-ups wouldn't be
that problematic anyway.
* 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
(--update must be given as first option, but can be followed by others)
* added simple perl scripts that is used by configure to convert BuildSetup
from jam to shell format
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34896 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Determine HOST_LD and HOST_OBJCOPY in configure.
* Removed Solaris ld work-around in BuildSetup.
The change requires configure to be re-run. Alternatively HOST_{LD,OBJCOPY}
can be added to generated/build/BuildConfig.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34892 a95241bf-73f2-0310-859d-f6bbb57e9c96
be run again or generated/build/BuildConfig needs to be adjusted manually.
* Removed bochs debug hack.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34721 a95241bf-73f2-0310-859d-f6bbb57e9c96
* BuildSetup: Set jam variable HOST_PLATFORM_IS_64_BIT and add host define
HAIKU_HOST_PLATFORM_64_BIT if the host platform is 64 bit. Removed the
check from BeOSBuildCompatibility.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34211 a95241bf-73f2-0310-859d-f6bbb57e9c96
build_cross_tools[_gcc4] script which in turn passes it to make. Cores and
hyperthreads are plentiful these days; no need to let most of them idle when
building the cross tools.
* Sorted the configure options alphabetically again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34199 a95241bf-73f2-0310-859d-f6bbb57e9c96
is obviously already configured not to use patented code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32577 a95241bf-73f2-0310-859d-f6bbb57e9c96
case-sensitive one. If not, print out a message and a link to the guide that
describes how to set one up.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30913 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also allow yasm 0.7.{0,1} -- they have been reported to successfully build
at least.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30152 a95241bf-73f2-0310-859d-f6bbb57e9c96
sets the HAIKU_YASM build variable, which will be checked in BuildSetup.
Re-running configure or adding the variable manually to
generated/build/BuildConfig is required.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30145 a95241bf-73f2-0310-859d-f6bbb57e9c96
--alternative-gcc-output-dir configure option has been specified,
HAIKU_ADD_ALTERNATIVE_GCC_LIBS is set by default. One has to explicitely
unset it in UserBuildConfig to avoid building the alternative gcc libs.
* Adjusted documentation accordingly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29607 a95241bf-73f2-0310-859d-f6bbb57e9c96
different directory layouts and this way we can still use a native compiler
as a cross compiler since we don't make the decision based on whether we are
cross compiling or not.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29082 a95241bf-73f2-0310-859d-f6bbb57e9c96
4). One has to have a (fully configured) "generated" directory for the
alternative gcc and specify it using the new option
"--alternative-gcc-output-dir" when configuring the main build.
Additionally the build variable HAIKU_ADD_ALTERNATIVE_GCC_LIBS has to be
set to "1".
If that has been done, when building the image a sub-jam is invoked that
generates the alternative libs and zips them. The main-jam unzips them
into the correct directory in the image. Note that the JAM build
variable has to be set when using a jam executable not invoked by "jam".
Tested with gcc 2 NetPositive, Pe, and FireFox under gcc 4 Haiku, and
with a few of the standard gcc 4 Haiku apps under gcc 2 Haiku. Seems to
work fine so far.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25536 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added sunos to the list of platforms, but it needs more work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24922 a95241bf-73f2-0310-859d-f6bbb57e9c96
gcc. You need to reconfigure and rebuild the cross-tools to have this
change take effect.
Note that from now on it is no longer possible to use the native BeOS
compiler to build Haiku. You'll have to build a cross compiler, too. I
haven't tested whether this works at all, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24542 a95241bf-73f2-0310-859d-f6bbb57e9c96
configure flag "--use-32bit" enabling 32 bit builds with a 64 bit host
compiler.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22046 a95241bf-73f2-0310-859d-f6bbb57e9c96
compatibility relation to the official Haiku distribution. "official"
is for the official Haiku distribution itself, "compatible" for Haiku
Compatible (tm) distros, and "default" for all others (the default value
for the option). The build system variable HAIKU_DISTRO_COMPATIBILITY is
defined accordingly, and one of the
HAIKU_DISTRO_COMPATIBILITY_{OFFICIAL,COMPATIBLE,DEFAULT} macros is
defined for source code and rdefs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21177 a95241bf-73f2-0310-859d-f6bbb57e9c96
building on Mac OS X (Darwin). A problem with makebootable remains.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21165 a95241bf-73f2-0310-859d-f6bbb57e9c96
xattrs. It can be enabled with the configure switch "--use-xattr". Note
that the amount of data stored in attributes may be limited by the used
file system -- e.g. AFAIK ext3 has a limit of one block (usually 4 KB)
for all attributes of a file, which might not suffice. XFS should be
fine, as should ReiserFS 3.6 (or any FS which stores attributes in
hidden files).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20609 a95241bf-73f2-0310-859d-f6bbb57e9c96
we do now check whether the target the compiler has been configured for
looks compatible.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20189 a95241bf-73f2-0310-859d-f6bbb57e9c96
Ingo Weinhold