Fix the build of test_app_server on 64bit

So many Jamfiles to search through...runs also, but there
are lots of graphical glitches

Change-Id: Ibf9e64566a5b8c5742792ac9b1b0f9ccc6693c8d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1753
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

Remove all invocations of SetSubDirSupportedPlatformsBeOSCompatible.

Use libstdc++, libsupc++ and libgcc from gcc_syslibs.

* Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so
from the gcc_syslibs build feature for everything except x86_gcc2.
* Use libgcc_s.so from the gcc_syslibs build feature for everything but
x86_gcc2 (which still carries libgcc as part of libroot.so).
* Drop filtering of libgcc objects for libroot, as that is no longer
necessary since we're only using libgcc-as-single-object for libroot
with x86_gcc2, where the filtered object file doesn't exist. Should
the objects that used to be filtered cause any problems as part of
libgcc_s.so, we can always filter them as part of the gcc build.
* Use libsupc++.so from the gcc_syslibs build feature for everything but
x86_gcc2.
* Adjust all Jamfiles accordingly.
* Deactivate building of faked libstdc++.so for non-x86-gcc2. For
x86_gcc2, we still build libstdc++.so from the sources in the Haiku
source tree as part of the Haiku build .
* Put gcc_syslibs package onto the image, when needed.

* merged 32bit-wchar_t branches of buildtools and haiku back into
the respective trunk

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31443 a95241bf-73f2-0310-859d-f6bbb57e9c96

One can now chose clipping or no clipping (--clipping or -c) and the drawing
mode. The ClippedLineTest is removed, since that was a dup of RandomLines
anyways.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29953 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added a SetupClipping() method to Test baseclass, which adds about 400
small clipping holes to the TestView user clipping.
* Added a bunch of new tests. Here are some numbers from the test environment,
which is similar to running Haiku in VESA mode:

Horizontal lines per second:
Haiku: 192964.663 (117,7%)
ZETA: 163977.006

Vertical lines per second:
Haiku: 90109.985 (276.9%)
ZETA: 32538.458

Random lines per second:
Haiku: 7998.451 (23.1%)
ZETA: 34602.539

Random colored lines per second:
Haiku: 7976.437 (22.9%)
ZETA: 34788.247

Random clipped lines per second:
Haiku: 262.180 (2.5%)
ZETA: 10394.794

Clipped glyphs per second:
Haiku: 5911.526 (1.0%)
ZETA: 590508.726

Obviously the clipping performance is a punch in the stomache.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26683 a95241bf-73f2-0310-859d-f6bbb57e9c96

The start of a benchmark application to test various performance questions
of the Haiku app_server. The immediate comparison are of course BeOS and ZETA.
Currently, it measures the performance of drawing untransformed text. For
now, I have only tested on ZETA and the app_server testing environment. Will
let you know my findings with Haiku running on real hardware.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26680 a95241bf-73f2-0310-859d-f6bbb57e9c96

Use libstdc++, libsupc++ and libgcc from gcc_syslibs.

* Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so
from the gcc_syslibs build feature for everything except x86_gcc2.
* Use libgcc_s.so from the gcc_syslibs build feature for everything but
x86_gcc2 (which still carries libgcc as part of libroot.so).
* Drop filtering of libgcc objects for libroot, as that is no longer
necessary since we're only using libgcc-as-single-object for libroot
with x86_gcc2, where the filtered object file doesn't exist. Should
the objects that used to be filtered cause any problems as part of
libgcc_s.so, we can always filter them as part of the gcc build.
* Use libsupc++.so from the gcc_syslibs build feature for everything but
x86_gcc2.
* Adjust all Jamfiles accordingly.
* Deactivate building of faked libstdc++.so for non-x86-gcc2. For
x86_gcc2, we still build libstdc++.so from the sources in the Haiku
source tree as part of the Haiku build .
* Put gcc_syslibs package onto the image, when needed.

* merged 32bit-wchar_t branches of buildtools and haiku back into
the respective trunk

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31443 a95241bf-73f2-0310-859d-f6bbb57e9c96

One can now chose clipping or no clipping (--clipping or -c) and the drawing
mode. The ClippedLineTest is removed, since that was a dup of RandomLines
anyways.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29953 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added a SetupClipping() method to Test baseclass, which adds about 400
small clipping holes to the TestView user clipping.
* Added a bunch of new tests. Here are some numbers from the test environment,
which is similar to running Haiku in VESA mode:

Horizontal lines per second:
Haiku: 192964.663 (117,7%)
ZETA: 163977.006

Vertical lines per second:
Haiku: 90109.985 (276.9%)
ZETA: 32538.458

Random lines per second:
Haiku: 7998.451 (23.1%)
ZETA: 34602.539

Random colored lines per second:
Haiku: 7976.437 (22.9%)
ZETA: 34788.247

Random clipped lines per second:
Haiku: 262.180 (2.5%)
ZETA: 10394.794

Clipped glyphs per second:
Haiku: 5911.526 (1.0%)
ZETA: 590508.726

Obviously the clipping performance is a punch in the stomache.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26683 a95241bf-73f2-0310-859d-f6bbb57e9c96

The start of a benchmark application to test various performance questions
of the Haiku app_server. The immediate comparison are of course BeOS and ZETA.
Currently, it measures the performance of drawing untransformed text. For
now, I have only tested on ZETA and the app_server testing environment. Will
let you know my findings with Haiku running on real hardware.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26680 a95241bf-73f2-0310-859d-f6bbb57e9c96