Build: Add architecture rule for libshared.a.

- As suggested by Ingo, add libshared.a to the architecture name map.
This allows it to be linked by its short name like other frequently
used libraries.
- Adjust all Jamfiles referencing the lib accordingly.

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.

Renamed jam target to just "netfs".


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

Copied Ingo's netfs from the dark pit in which it was forgotten to something
more visible and ported it to the current UserlandFS server (and GCC4). It still
uses the R5 file system API, which the UserlandFS conveniently still provides
support for. It compiles and links, but is otherwise still untested. The changes
I am alsmost confident that I didn't change any semantics. That is unless
HashMap, HashString and DoublyLinkedList work differently enough to make any of
the netfs code break.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35081 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.

Renamed jam target to just "netfs".


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

Copied Ingo's netfs from the dark pit in which it was forgotten to something
more visible and ported it to the current UserlandFS server (and GCC4). It still
uses the R5 file system API, which the UserlandFS conveniently still provides
support for. It compiles and links, but is otherwise still untested. The changes
I am alsmost confident that I didn't change any semantics. That is unless
HashMap, HashString and DoublyLinkedList work differently enough to make any of
the netfs code break.


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