Cortex: fix the catalog location of the main application

Previously, hrev55011 introduced localization for Cortex, which then
prompted to close #7530. It has then been reopened, when it turns out
th

Cortex: fix the catalog location of the main application

Previously, hrev55011 introduced localization for Cortex, which then
prompted to close #7530. It has then been reopened, when it turns out
that the translations for the container application (RouteApp) did not
work, whereas the individual add-ons/modules were translated.

The cause is that by default BCatalog looks up the translations based on
the subtype part of the signature. This is x-vnd.Cortex.Route (without
the application/ supertype). This change will place the translations in
the right place of the file system.

The add-ons were never affected, since they BCatalog is explicitly told
to find the translations for the entire signature, like:

static BCatalog sCatalog("application/x-vnd.Cortex.InfoView");

Even so, it was chosen to omit the `application` supertype from the
signature for the shared code as well.

This should fix #7530 for good.

Change-Id: Iff18fabef7aba68602e49db1e98cfed2f486f545
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4091
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

show more ...

Added localization support for Cortex app.

* Fixes #7530.

Change-Id: I238c4c8fe32b181a8e1a4bd688bcbe9f3a87f79f
Signed-off-by: Kacper Kasper <kacperkasper@gmail.com>
Reviewed-on: https://review.haik

Added localization support for Cortex app.

* Fixes #7530.

Change-Id: I238c4c8fe32b181a8e1a4bd688bcbe9f3a87f79f
Signed-off-by: Kacper Kasper <kacperkasper@gmail.com>
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3169
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

show more ...

Cortex: convert remaining RSRCs to RDEFs.

Merge branch 'gcc_syslibs'

* From now on, the gcc-specific system libraries (libgcc, libsupc++ and
libstdc++) are provided by separate packages built along with gcc:
- gcc_syslibs contains the s

Merge branch 'gcc_syslibs'

* From now on, the gcc-specific system libraries (libgcc, libsupc++ and
libstdc++) are provided by separate packages built along with gcc:
- gcc_syslibs contains the shared libraries (libgcc_s.so, libsupc++.so and
libstdc++.so)
- gcc_syslibs_devel contains the static libraries and both c++ and gcc
headers
The shared libraries now make proper use of symbol versioning and there
are version-specific symlinks
* The buildsystem has been adjusted to no longer use the libraries and
headers from the cross-compiler, but use the ones provided by the
above-mentioned packages. The only exception is that the 32-bit libraries
required for the bootloader of the x86_64 architecture are still taken
from the cross-compiler.

show more ...

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 l

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.

show more ...

* 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

* Added Flanger and AudioAdapter audio addons from Cortex to the build
* Actually I could only try if they build and work inside the vm, I do not have sound available somewhere, so could please someo

* Added Flanger and AudioAdapter audio addons from Cortex to the build
* Actually I could only try if they build and work inside the vm, I do not have sound available somewhere, so could please someone test whether the results are reasonable? They cannot be added to the image until someone approves that they are working fine...
* got rid of most compiler warnings



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

show more ...