adjusting it where I figured it necessary.
* Disabled the --no-beos-fixes option for Haiku.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@24513 a95241bf-73f2-0310-859d-f6bbb57e9c96
problem, since only the copies of gcc headers in the haiku module are
used.
BeOS/Haiku requires sizeof(bool) to be 1.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@24512 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Rebuilt the build system using the patched automake/-conf/libtool.
* Didn't touch ltconfig, libtool.m4, and lt-*. They look somehow
obsolete. Need to recheck later.
NOTE: Those changes are untested yet. Don't update!
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@24508 a95241bf-73f2-0310-859d-f6bbb57e9c96
link-order.test, which seems to require ld support for undefined symbols
in libraries. We'll review that after bootstrapping Haiku native
binutils and gcc.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@24504 a95241bf-73f2-0310-859d-f6bbb57e9c96
instsh2.test, which fails by design when running with root privileges.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@24503 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Built with debugging enabled (-O0 -g).
* No support for sockets or threads yet. We do want those eventually,
though.
* 6 tests of Perl's test suite fail. 2 due to missing sockets support. 4
others since they compile modules and make no provisions to link
against libperl.so, which they should. Have to check back with the
maintainters.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@24460 a95241bf-73f2-0310-859d-f6bbb57e9c96
this finally fixes bug #1608 and enables to print correctly long double values.
It should now be possible to revert r21883.
I hope this change has no consequences on binary compatibility (it shouldn't). Oliver, please review.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@23127 a95241bf-73f2-0310-859d-f6bbb57e9c96
Wonder why it doesn't happen on x86 ? (maybe cause comment chars are different ?)
cf. http://sources.redhat.com/ml/binutils/2004-04/msg00646.html
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@22737 a95241bf-73f2-0310-859d-f6bbb57e9c96
* A Node can no longer have a referring "." or ".." Entry (except the root
directory), not even temporarily. This rules out cycles when resolving
paths.
* Made the code more robust against missed node monitoring messages. If
an entry is encountered that shouldn't be there, it is removed. As
implemented before, a Node could end up with a NULL referring Entry,
leading to a crash when an Entry that references the Node was moved.
Missing node monitoring messages is actually virtually impossible,
since a dedicated looper does nothing else but pushing those into a
separate queue, but nevertheless Stippi seems to have managed the trick. :-)
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@21307 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Solved conflicts with the libtool related files by simply using the
vendor versions. IIRC the haiku related changes to libtool and
autoconf were relevant only for the binutils.
* Solved {libstdc++-v3,libmudflap}/configure conflicts by re-running
autoconf for these directories.
I'm already working on fixing the Haiku build, so please don't do the
same.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@20318 a95241bf-73f2-0310-859d-f6bbb57e9c96
except one: the binaries produced by this version of binutils crashes the loader of
BeOS versions BONE, Dano (and probably Zeta, too). That's a pity, but I currently
do not know how to fix this (as the fix available for older versions of binutils
does not work anymore).
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@20192 a95241bf-73f2-0310-859d-f6bbb57e9c96
except one: the binaries produced by this version of binutils crashes the loader of
BeOS versions BONE, Dano (and probably Zeta, too). That's a pity, but I currently
do not know how to fix this (as the fix available for older versions of binutils
does not work anymore).
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@20191 a95241bf-73f2-0310-859d-f6bbb57e9c96
This fixes one fo the problems of building gcc4 under Zeta.
See http://gcc.gnu.org/ml/gcc/2003-10/msg01501.html
If you want to try you'll have to also remove the -lm in gcc/gcc/Makefile.in or symlink it to libroot.so.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@20115 a95241bf-73f2-0310-859d-f6bbb57e9c96
The removed header fixes don't apply to the Haiku headers anyway, so
this shouldn't be much of a problem.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@20046 a95241bf-73f2-0310-859d-f6bbb57e9c96
should be built lives in the 'legacy' folder. This confused several people (and
rightly so >;o).
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@18630 a95241bf-73f2-0310-859d-f6bbb57e9c96
possible to differentiate all the jam-versions out there...
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@18505 a95241bf-73f2-0310-859d-f6bbb57e9c96
children (as created by piped commands). This caused the compilation
of AboutHaiku to fail on Zeta.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@18503 a95241bf-73f2-0310-859d-f6bbb57e9c96
In fact, BeIDE seems to delete the entry and move a temp entry to the right place:
StatCacheServer was then thinking that the entry was removed
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@17926 a95241bf-73f2-0310-859d-f6bbb57e9c96
We no longer even try to do that. The user can define the environment variable
RC, if they want StatCacheServer resources, otherwise they will just not be
added (a respective note is printed).
Closes bug #176.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@16533 a95241bf-73f2-0310-859d-f6bbb57e9c96
the targets given on the command line (respectively "all", if none
has been given). The contents of the variable can be changed from
within the Jamrules/Jamfiles. The targets that are in JAM_TARGETS
after Jamfile parsing is done, are those that will be built (and their
dependencies, of course). This allows for interesting build system
features.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@16345 a95241bf-73f2-0310-859d-f6bbb57e9c96
