glibc 2.3.2, which seems to be the version used in other places,
though I also found older files.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15402 a95241bf-73f2-0310-859d-f6bbb57e9c96
system happy for the time being. We need real setjmp()/longjmp()
implementations for PPC eventually, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15401 a95241bf-73f2-0310-859d-f6bbb57e9c96
to make the build system happy for now. We'll see later what we
have to do.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15400 a95241bf-73f2-0310-859d-f6bbb57e9c96
build tools as well. The configure option --build-cross-tools-gcc4 has a
new parameter to specify the architecture.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15382 a95241bf-73f2-0310-859d-f6bbb57e9c96
the sizes and alignments of syscall parameters. It no longer
generates and compiles functions with the same signature as the
syscalls. This simply doesn't generally work for cross-compilation.
Instead we provide a bit of architecture-specific code that knows
how things work for the target architecture.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15196 a95241bf-73f2-0310-859d-f6bbb57e9c96
Each component is built in the respective subdirectory now
and no longer in src/system/Jamfile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15184 a95241bf-73f2-0310-859d-f6bbb57e9c96
one being $(1:S=$(SUFLIB)). Thus the wrong AR would be used when
the name passed to LibraryFromObjects didn't have the .a suffix yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15029 a95241bf-73f2-0310-859d-f6bbb57e9c96
from the sources. Added respective configure option
--build-cross-tools-gcc4.
* Fixed running "configure --build-cross-tools" from another directory
than the source dir. The parameter to the script was missing and thus
the tools were created in <sources>/generated.
* Removed stdc++ lib header dir ".../debug". One is supposed to include
<debug/...> to get the debug headers.
* The stdc++ lib header dirs are now listed one per line in the
generated BuildConfig. This works around the 512 bytes jam line length
limit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15020 a95241bf-73f2-0310-859d-f6bbb57e9c96
kernel. They are now the sizes of the allocated areas, which might be a
bit more than the actually used size, but at least they are not
potentially less, as they were before. This could have unexpected
effects like the Tracker not finding its resources...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14977 a95241bf-73f2-0310-859d-f6bbb57e9c96
ignored and the line concatenated with the next one -- making it a
comment, too. Either a bug or a newly implemented feature.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14974 a95241bf-73f2-0310-859d-f6bbb57e9c96
doesn't link against libsupc++ and still needs the symbol.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14972 a95241bf-73f2-0310-859d-f6bbb57e9c96
wonder why things worked nevertheless with the old gcc). We now also use
realloc() instead of malloc()+memcpy(), and check add_variable()'s
return code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14957 a95241bf-73f2-0310-859d-f6bbb57e9c96
provides it via BuildConfig. We link everything against it.
* Temporarily pass --no-undefined to the linker. Should be in the
compiler specs, but isn't in the gcc 4 I built.
* Define _BEOS_R5_COMPATIBLE_ macro when building with gcc 2. Can be
used in headers for instance.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14913 a95241bf-73f2-0310-859d-f6bbb57e9c96
other compilation units too. gcc 4 is quite consequent and doesn't
generate non-inlined code for such a function.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14912 a95241bf-73f2-0310-859d-f6bbb57e9c96
space inbetween. The segments can be in inverse order now, too.
The same should be done in the kernel, too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14907 a95241bf-73f2-0310-859d-f6bbb57e9c96
which could cause the __ctor_list pointer to be off.
PS: We can get rid of most of the ld scripts. ATM only kernel.ld,
boot_loader.ld, and add-on.ld are still in use. The latter one probably
unnecessarily.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14905 a95241bf-73f2-0310-859d-f6bbb57e9c96
be legal. This might even fix the bug that build tools like xres or
settype couldn't find an existing file under Linux (was never able to
reproduce that one, though).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14900 a95241bf-73f2-0310-859d-f6bbb57e9c96
categories:
* Missing includes (like <stdlib.h> and <string.h>).
* Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so.
* Local variables shadowing parameters.
* Default parameters in function definitions (as opposed to function
declarations).
* All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported
explicitly from the std:: namespace now.
* "new (sometype)[...]" must read "new sometype[...]", even if sometype is
something like "const char *".
* __FUNCTION__ is no longer a string literal (but a string expression), i.e.
'printf(__FUNCTION__ ": ...\n")' is invalid code.
* A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes"
is an invalid expression.
* "friend class SomeClass" only works when SomeClass is known before.
Otherwise the an inner class with that name is considered as friend.
gcc 4 is much pickier about scopes.
* gcc 4 is generally stricter with respect to type conversions in C.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96
we use the libstdc++ (including it's headers) that comes with the
compiler.
* Apparently option "-I-" has been deprecated, which is why we now treat the
include stuff a bit differently.
* Removed avcodec from the Haiku image, since the library wouldn't build with
gcc 4, and I'm not in the mood to fix that (declaration of an array of an
incomplete type).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14876 a95241bf-73f2-0310-859d-f6bbb57e9c96
my brain by trying to understand code using gotos. People, learn
structured programming!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14870 a95241bf-73f2-0310-859d-f6bbb57e9c96
a few whether they actually work.
New pseudo target "unittests", which builds all unit tests for the currently
set TARGET_PLATFORM. They are placed in generated/tests/<platform>/unittests.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14791 a95241bf-73f2-0310-859d-f6bbb57e9c96
Library names are now mapped for all targets but "host" (not only for
"haiku") -- added one more level of indirection to achieve that.
(TARGET_LIBRARY_NAME_MAP -> *_LIBRARY_NAME_MAP_*).
* Renamed build/HaikuBuildCompatibility.h to BeOSBuildCompatibility.h
(auto-included when compiling something that uses the Be API for platform
"host" on anon-BeOS platform), and introduced build/HaikuBuildCompatibility.h,
which can be included when compiling something that can be built for both,
Haiku and BeOS compatible platforms.
* Introduced libhaikucompat.a, a library that adds a few functions existing
under Haiku, but not under BeOS.
* New rule AddSubDirSupportedPlatforms.
* Renamed libopenbeos.so to libbe_haiku.so.
* Introduced new target platform "libbe_test", which is basically equivalent
to a BeOS compatible host platform target, with the exception, that instead
of the host platform's libbe.so a special build of Haiku's libbe.so
(libbe_haiku.so (formerly known as libopenbeos.so)) is used. Furthermore
Haiku's public app, interface, storage, and support kit headers are used
when compiling. This replaces the less nice way in which the test app server
and applications for this test environment were built.
When building for platform "libbe_test", the library name "be" is
autotranslated to "libbe_haiku.so". Thus most applications don't need
special fiddling when them building them for the app server test environment;
usually an "AddSubDirSupportedPlatforms libbe_test ;" will suffice.
* Reduced the dependencies of <syscalls.h> and fixed problems caused by this
(e.g. source files not including the needed headers directly).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14749 a95241bf-73f2-0310-859d-f6bbb57e9c96
doesn't work quite well when symbols are not loaded -- e.g. stack crawls
are usually broken. Also stack crawls ending in a syscall work. gdb can
deal well enough with frameless function, which I realized, of course,
only after writing code for explicitly supporting syscall functions.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14680 a95241bf-73f2-0310-859d-f6bbb57e9c96
UseLegacyHeaders and UseLegacyObjectHeaders to use them.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14664 a95241bf-73f2-0310-859d-f6bbb57e9c96
* When being asked for a thread's CPU state, we stop the thread now. Not
sure, if that is as it is supposed to work, but I don't see any other
way. A side effect is that "info threads" will stop all threads.
Another side effect is, that switching between threads should now work
properly. Unless there is another problem, I'm not aware of, that is.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14663 a95241bf-73f2-0310-859d-f6bbb57e9c96
to the parameters nor the number of parameters; the kernel is able to
get both without problems.
The syscall functions in libroot (_kern_*()) are now self-contained
(they don't "jmp" to separate code anymore), which at least
theoretically allows gdb to print a stack trace with the syscall
function on the top when a thread is currently performing a syscall.
Practically it doesn't work yet, though, since those functions are
frameless (i.e. create no stack frame) which needs special support
I haven't implemented yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14661 a95241bf-73f2-0310-859d-f6bbb57e9c96
* To always be on the safe side, thread_hit_debug_event() now checks
whether the thread is the debug nub thread.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14655 a95241bf-73f2-0310-859d-f6bbb57e9c96
exception that it turns on debugging for the target by default (unless
NO_TEST_DEBUG is defined or DEBUG has been overridden before).
Note, that SimpleTest makes no assumptions about the supported target
platforms. So, if the target should be buildable for other platforms
than Haiku, that has to be specified.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14653 a95241bf-73f2-0310-859d-f6bbb57e9c96
Some add-ons don't build, since they include non-R5 networking headers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14598 a95241bf-73f2-0310-859d-f6bbb57e9c96
src/tests/servers/app/Jamfile. This makes the original Jamfile much cleaner.
Note that you now have to maintain two Jamfiles when adding/removing sources.
The test app server is called haiku_app_server, its library
libhaikuappserver.so. I adjusted a few paths in scripts accordingly, but
I may have missed something elsewhere.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13858 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added the respective case statement in AppServer::DispatchMessage().
The code that actually activates the app is still missing.
* Removed the remnants of the old way of notifying the registrar about
what app got activated (the activated client window did that).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13820 a95241bf-73f2-0310-859d-f6bbb57e9c96
their path could be invalid in other contexts (e.g. the debug server might
be unabled to find them). This seems to be what BeOS does, too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13796 a95241bf-73f2-0310-859d-f6bbb57e9c96
user application performs a division by zero or causes a general
protection fault. For some exceptions (e.g. machine check) I wasn't
quite sure whether they can be caused by user apps at all, so we panic()
in those cases. Wouldn't harm, if someone more knowledgable would check
this, though.
* Removed the unused fault handling stuff, respectively moved the little
that was used into x86/arch_int.c.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13795 a95241bf-73f2-0310-859d-f6bbb57e9c96
Ingo Weinhold