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
grist caused bfd to be compiled using gdb's config.h. This made it think
Haiku had no fcntl() and thus assumed shared objects were opened r/w instead
of read-only, which made it write back data when closing the files. So this
fixes the problem that gdb damages the shared objects it had loaded.
Basically two questions remain:
1) Why does BFD write something into the files that makes them invalid?
2) Why was it possible to write something into the read-only opened files?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13791 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Print the debugger message in case the debugged team called debugger(),
and the description of an occurred exception respectively.
* Properly keep gdb's internal thread list up to date. This fixes the
problem that an attached debugger always resumed all threads of the
debugged team.
* A bit of cleanup of the attaching code.
Discovered an ugly bug: When invoking gdb with an executable -- regardless
of whether attaching gdb to a running process or just starting a debugger
session with the executable -- the executable is modified. I tested with
"crashing_app" and in the second debug session gdb fails to read the debug
info from the file and encounters a weird error when closing the file:
"No space left on device." I have the suspicion that this is another bug
in Axel's VM/file cache pet. :-P
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13775 a95241bf-73f2-0310-859d-f6bbb57e9c96
implementations (e.g. SVR4) don't do that, but I don't see how it could
work otherwise. Maybe other systems place the executable's code exactly
where specified in the executable and hence noone ever noticed...
Anyway, this makes stack traces (and probably other things that were broken
before) work with an attached gdb.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13762 a95241bf-73f2-0310-859d-f6bbb57e9c96
concerned shared object's file, which probably is a bit overkill) and added
respective comments.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13725 a95241bf-73f2-0310-859d-f6bbb57e9c96
Deskbar to initiate the shutdown process asynchronously. Couldn't test it,
because opening the Be menu doesn't work:
***PANIC: BW: Can't find view with ID: 19 !***
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13722 a95241bf-73f2-0310-859d-f6bbb57e9c96
debug_server uses this feature to print stack traces with symbols.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13698 a95241bf-73f2-0310-859d-f6bbb57e9c96
Ingo Weinhold