* 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
be compiled (it requires a c++-compiler, of course).
This fixes the build on R5.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@16140 a95241bf-73f2-0310-859d-f6bbb57e9c96
generate "correct" (aka BeOS-specific) symbols when using the cross
compiler, too.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@16119 a95241bf-73f2-0310-859d-f6bbb57e9c96
The value defined for ld must be the same, since otherwise one gets
effects like we had for generated PPC objects: The BFD page size was
0x10000, the ld page size 0x1000. Thus the data segment alignment forced
in the linker script didn't allow BFD to really start a new segment
(unless by accident a 0x10000 boundary was crossed as well). Hence our
libraries and executables only had one loadable segment (containing both
text and data), which neither of the three Haiku ELF loaders (in boot
loader, kernel, and userland) likes at all.
As a fix we force 0x1000 page size for target Haiku in a similar way it
is done for QNX.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@15705 a95241bf-73f2-0310-859d-f6bbb57e9c96
for x86), so it should be placed near the .bss sections. This fixes
linkage problems -- the linker had to split the text segment after the
.plt section, which caused its pre-computed program header count to be
wrong.
* I also added the stuff concerning the .fixup and .got{1,2} sections I
found in the generic ELF PPC script. It shouldn't harm at least.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@15474 a95241bf-73f2-0310-859d-f6bbb57e9c96
The i386-pc-haiku no longer uses the BeOS BFD target emulation, but
its own. A few things are shared for both *-*-haiku machines now.
The PowerPC Haiku binutils and gcc build, but I wouldn't expect them
to really produce usable output yet. We'll see...
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@15381 a95241bf-73f2-0310-859d-f6bbb57e9c96
