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
mostly copy'n'pasted from the Linux/FreeBSD configuration.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@15000 a95241bf-73f2-0310-859d-f6bbb57e9c96
cause some headers not to be found. Rather fix the test for finding
<limits.h>.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@14998 a95241bf-73f2-0310-859d-f6bbb57e9c96
keeps the JCR section (Java support stuff) from being created. A bit hacky.
There's the target define TARGET_USE_JCR_SECTION which is documented to be
used to disable it, but AFAI have seen it is never evaluated.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@14995 a95241bf-73f2-0310-859d-f6bbb57e9c96
Threading support. I wonder whether the mutexes should better be
semaphores/benaphores, though.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@14994 a95241bf-73f2-0310-859d-f6bbb57e9c96
probably originally by Oliver). We additionally let gcc define
__GXX_MERGED_TYPEINFO_NAMES, which solves RTTI problems due to the fact
that a type_info for a class can exist in multiple times.
git-svn-id: file:///srv/svn/repos/haiku/buildtools/trunk@14993 a95241bf-73f2-0310-859d-f6bbb57e9c96
structs and unions in C as well as in C++ (application of this patch has
been sugggested by execom through BeBits-talkback).
This mail-thread explains the problem & solution:
http://gcc.gnu.org/ml/gcc-bugs/1999-08n/msg00914.html
These are the patches that have been applied:
gcc-2.95-anon-struct-union.diff
gcc-2.95-c++-tidy.diff
gcc-2.95-c++-anon-struct.diff
gcc-2.95-c++-anon-struct2.diff
which can all be found here:
ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/gcc-2.95/patches/
git-svn-id: file:///srv/svn/repos/haiku/trunk/buildtools@11421 a95241bf-73f2-0310-859d-f6bbb57e9c96
cross-compiling with BeOS target works.
- tweaked build-procedure to allow for proper generation of a i586-pc-beos
cross-compiler on LINUX.
- added documentation for creation of cross-compiler.
git-svn-id: file:///srv/svn/repos/haiku/trunk/buildtools@11255 a95241bf-73f2-0310-859d-f6bbb57e9c96
depend on less tools.
- culled gettext, libdl and libiconv from the tool-list Axel had just added.
Only autoconf and automake should be needed now
[Axel: I have checked this just now on my machine, but please correct me
if I'm still wrong!]
git-svn-id: file:///srv/svn/repos/haiku/trunk/buildtools@11254 a95241bf-73f2-0310-859d-f6bbb57e9c96
built during the make process. Before, it was being built during the
install process, when gcc might not be available, if the install goes
into an empty folder. Now, installs in empty folders work properly.
git-svn-id: file:///srv/svn/repos/haiku/trunk/buildtools@11253 a95241bf-73f2-0310-859d-f6bbb57e9c96
