userlandfs: use std::bitset for FSCapabilities

gcc 13 is confused by the custom bitset implementation, so use the C++
standard one instead.

However, this results in including the C++ <string> heade

userlandfs: use std::bitset for FSCapabilities

gcc 13 is confused by the custom bitset implementation, so use the C++
standard one instead.

However, this results in including the C++ <string> header in kernel
code. This doesn't work for gcc2, because of two problems:

- That header includes a declaration of atomic_add that doesn't match
the one in SupportsDefs.h (which can in some cases replace the function
with a #define for an inline version). Adjust the header to use the
be a problem because it creates a risk of circular inclusions.
Standard C++ headers shouldn't depend on BeAPI ones.
- It also leads to the inclusion of iostream which defined lock and
unlock functions in the global namespace. We don't want these, and they
are not part of the C++ standard, so just remove them.

Ideally we could use std::hash for the GetHashCode implementation, but
that doesn't work because it depends on an helper function that's in
libstdc++, and we can't link that from kernel add-ons.

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

show more ...

userlandfs: libbsd.so is referenced as "libbsd.so".

Fixes the build.

Use explicit_bzero where it makes sense

PVS studio new report, warning type V597

Change-Id: Icd85aadf3ffc587806f9a24d224d0a369d4ce0e0
Reviewed-on: https://review.haiku-os.org/c/1594
Reviewed-by: wa

Use explicit_bzero where it makes sense

PVS studio new report, warning type V597

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

show more ...

userlandfs: Fix build breakage on GCC2.

userlandfs: Fix the BeOS frontend on 64-bit.

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

* Renamed UserlandFSServer to userlandfs_server. It is expected to live in
/system/servers, now.
* Got rid of the dispatcher application. It was the entity the kernel module
talked to when mounti

* Renamed UserlandFSServer to userlandfs_server. It is expected to live in
/system/servers, now.
* Got rid of the dispatcher application. It was the entity the kernel module
talked to when mounting a yet unknown FS. It started the client FS server
applications. Now the kernel module starts them directly. They use
respectively named ports, so the kernel module can find them when already
running.


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

show more ...

Renamed files (removed "beos_" prefix).


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

* Reorganized the sources. Haiku and BeOS kernel interface each have their own
subdirectory, now.
* Moved all code specific to a kernel interface into the respective library.


git-svn-id: file:///

* Reorganized the sources. Haiku and BeOS kernel interface each have their own
subdirectory, now.
* Moved all code specific to a kernel interface into the respective library.


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

show more ...