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 ...

Bring the hybrid translators back into the image.

Merge branch 'package-management'

Conflicts:
src/preferences/network/Jamfile

More work towards hybrid support

* All packaging architecture dependent variables do now have a
respective suffix and are set up for each configured packaging
architecture, save for the kernel a

More work towards hybrid support

* All packaging architecture dependent variables do now have a
respective suffix and are set up for each configured packaging
architecture, save for the kernel and boot loader variables, which
are still only set up for the primary architecture.
For convenience TARGET_PACKAGING_ARCH, TARGET_ARCH, TARGET_LIBSUPC++,
and TARGET_LIBSTDC++ are set to the respective values for the primary
packaging architecture by default.
* Introduce a set of MultiArch* rules to help with building targets for
multiple packaging architectures. Generally the respective targets are
(additionally) gristed with the packaging architecture. For libraries
the additional grist is usually omitted for the primary architecture
(e.g. libroot.so and <x86>libroot.so for x86_gcc2/x86 hybrid), so that
Jamfiles for targets built only for the primary architecture don't
need to be changed.
* Add multi-arch build support for all targets needed for the stage 1
cross devel package as well as for libbe (untested).

show more ...

Moved IconUtils.h to Interface Kit and therefor made it an "official" header. Since the class has no
virtual but only static methods, it is not so likely that binary compatibility issues may arrise
f

Moved IconUtils.h to Interface Kit and therefor made it an "official" header. Since the class has no
virtual but only static methods, it is not so likely that binary compatibility issues may arrise
from using it in new apps. Adjusted all the Jamfiles that included the private libicon headers. Note
that it was never necessary to link against libicon.a, since it's part of libbe anyway. There was one
instance where that was done. Hopefully it does not break the build, but I did this change a while ago,
tested it and then the harddrive began failing.


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

show more ...

Applied following patches proposed by Jorma Karvonen:
#7135 #7140 #7141 #7145 #7186 #7188 #7191
#7136 #7187 #7184 #7185 #7192 #7138 #7139

with some changes and exclusions:
- all attempts to loca

Applied following patches proposed by Jorma Karvonen:
#7135 #7140 #7141 #7145 #7186 #7188 #7191
#7136 #7187 #7184 #7185 #7192 #7138 #7139

with some changes and exclusions:
- all attempts to localize "fprintf(stderr,..." and "printf(..."
replaced by _untranslated_ "syslog(LOG_ERR ...";
- following *Translator.rdef files, that were not added in mentioned patches
were additionally created:
SGI, TIFF, RAW, RTF, PPM, WebP, EXR, STXT, WonderBrush, GIF, TGA;
- some small fixes for consistent catalogs building.

Thank you, Jorma! Please check. ;-)



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

show more ...

Applied patchs from Karvjorm (tickets #7125, #7131, #7126, #7129): Localizations for PNG PCX HVIF and HPGS translators.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40262 a95241bf-73f2-0310-

Applied patchs from Karvjorm (tickets #7125, #7131, #7126, #7129): Localizations for PNG PCX HVIF and HPGS translators.


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

show more ...

Fix translator builds.



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

* 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

Adding a BIconUtils based HVIFTranslator. It's not very efficient as it does
the full work twice in the worst case. Also since it only supports actual HVIF
format and not the Icon-O-Matic one directl

Adding a BIconUtils based HVIFTranslator. It's not very efficient as it does
the full work twice in the worst case. Also since it only supports actual HVIF
format and not the Icon-O-Matic one directly it is not as useful as one might
think. Still it's a start. You could translate from a HVIF file to a PNG using
the command line translate tool with it (translate infile outfile 'PNG ').


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

show more ...