Why did I even consider running the current autotools against almost two
years old code? Of course it wouldn't work.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@24518 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
