menu. The menu basically works, but has a couple of problems. The
harmless ones are graphical: we get cursor artifacts when the colors
are changed, and the item selection doesn't quite look as it should.
More serious is the lack of Home/End, Page Up/Down keys. All I read from
the console is a '\0' byte when such a key is pressed. The cursor keys
work fortunately. I mapped the functionality of Page Up/Down
additionally to the Left/Right cursor keys. So the menu should be usable
at least. I guess, I'll leave it in that state; Axel wants a graphical
menu anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15589 a95241bf-73f2-0310-859d-f6bbb57e9c96
effect that we were linking not only against the complete glue code, but
also against libroot.so. Now we explicitly link against
crtbegin.o/crtend.o only.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15545 a95241bf-73f2-0310-859d-f6bbb57e9c96
author ever checked the documentation for the function he was trying to
use.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15492 a95241bf-73f2-0310-859d-f6bbb57e9c96
suboptimal (if working at all) -- review is appreciated.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15486 a95241bf-73f2-0310-859d-f6bbb57e9c96
easier to define them for now, since they are used unconditionally e.g.
in the Tracker sources.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15485 a95241bf-73f2-0310-859d-f6bbb57e9c96
one of the TODOs already says, the architecture specific parts should be
factored out into separate source files.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15480 a95241bf-73f2-0310-859d-f6bbb57e9c96
but it compiles at least. :-)
* Pulled the architecture specific part out of <posix/setjmp.h> into
<posix/arch/<arch>/arch_setjmp.h>.
* Moved setjmp_save_sigs.c from the x86 specific implementation into a
"generic" sibling directory, since it is reusable (and actually used
by the PPC implementation).
* Added generic/longjmp_return.c containing a function __longjmp_return,
which is invoked at the end of siglongjmp(), resetting the signal mask
and validating the return value. It is used by the PPC implementation,
and should also be used by the x86 implementation, but I'll leave that
to someone who's motivated enough to also test it. :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15479 a95241bf-73f2-0310-859d-f6bbb57e9c96
functions from glibc 2.3.2. Adding those one by one is extremely
boring and time-consuming work. We should probably just remove the
math stuff again, add a verbatim copy of the glibc directories, and
shuffle things around afterwards.
* Note that for x86 holds sizeof(long double) == 96. I removed the
generic 128 bit long double functions that were in use before and
added respective 96 bit versions to arch/x86 (or left them out, if
they weren't used). For PPC the System V ABI spec supplement specifies
sizeof(long double) == 128, but I had trouble configuring gcc to
actually use that setting (looks like there simply is no support for
TI mode for PPC 32). So we have to live with sizeof(long double) ==
sizeof(double) == 64 for the time being.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15477 a95241bf-73f2-0310-859d-f6bbb57e9c96
inline. Commented undefined virtual methods. BBitmapBuffer is still used, so
is ViewHWInterface.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15472 a95241bf-73f2-0310-859d-f6bbb57e9c96
x86 the Haiku image still builds, so it is apparently not used. I
guess it would be best to abandon our posix_math.o completely and
use the glibc math implementations instead.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15446 a95241bf-73f2-0310-859d-f6bbb57e9c96
added a generic implementation using atomic_test_and_set().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15444 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
Ingo Weinhold