only adds a guard against the inclusion of <netinet/in_systm.h>, which
Haiku doesn't have ATM (we should probably just add it). Following the
instructions in my Notes file everything builds and the results run
somewhat. ssh has problems with a Sun server I tested against (all
OpenSSH servers worked fine, though), sftp is broken, and sshd refuses
to work without a "sshd" user for privilege separation. Well, I'm
working on it...
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@24695 a95241bf-73f2-0310-859d-f6bbb57e9c96
all tests of the test suite just passed.
* Also added a file with a few notes.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@24692 a95241bf-73f2-0310-859d-f6bbb57e9c96
it accidentally when editing the patch. Anyway, this skips the
stat::st_atime test, as BFS doesn't maintain it correctly.
* Cleaned up the Haiku hints script a little: Don't compile with
debugging anymore, set the paths correctly (reordered, include
/boot/common), and don't define __HAIKU__ anymore, as the native
compiler does that anyway.
Only 3 tests of the test suite fail now -- 2 due to missing sockets
support, one due to a problem with exec*() or system(). Will have to
investigate this further.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@24562 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
