History log of /haiku/src/build/libroot/function_remapper.cpp
Revision Date Author Comments
# d2845248 12-Jun-2018 Jessica Hamilton <jessica.l.hamilton@gmail.com>

libroot_build: replace void* with addr_t for hidden functions.

* Using attribute visibility hidden doesn't get applied if a
function returns a non-class pointer type, so the functions
weren't being hidden for gcc4+ builds, resulting in stack
overflows. Using addr_t, which should be the same size as
void* works around this restriction.


# 648f0d5f 14-Apr-2018 Augustin Cavalier <waddlesplash@gmail.com>

libroot_build: Properly remap fs_attr_* functions.

This was done using macros before, which isn't the way we have things set up.
In theory that method should work, however if not all consumers include the
libroot_build headers properly, then it breaks in subtle but confusing ways,
which is not what we want at all.

Thanks to Jessica for advice.

Change-Id: Idd45df5547daecf8239932957088da03ddfccf87


# 5e19679e 13-Dec-2017 Augustin Cavalier <waddlesplash@gmail.com>

build: Use libroot_build on Haiku.

Previously we just used the system libroot, which of course meant
that when libroot's ABI changed, the build broke. Now we use the full
libroot_build that we do on non-Haiku platforms. The logic for "BeOS-compatible
but not Haiku" does not really apply anymore, so it has been gutted where
appropriate (and libhaikucompat has been decoupled from the build.)

The only caveat here is the change to Errors.h -- we really should be using
the system's one where I included the one from the tree, but for whatever
reason, GCC2 refused to handle the #include_next properly.

Fixes the build breakage of Haiku-on-Haiku by my prior commits (sorry).


# 55bc3719 30-Jun-2011 Ingo Weinhold <ingo_weinhold@gmx.de>

Wrap POSIX FD functions in libroot_build

This makes opening symlinks work universally in the build system tools.
Two mechanisms have been implemented, both of which don't always work.
The first is remapping via preprocessor macros. This fails where equally
named methods are used (e.g. STL fstream::open()). The other is using
hidden functions in the new libroot_build_function_remapper.a that is
linked into everything that is linked against libroot_build.so. This one
fails for functions that are defined inline in headers (Linux/glibc does
that). Together they seem to cover our build system needs ATM.


# 4dbc2457 30-Jun-2011 Ingo Weinhold <ingo_weinhold@gmx.de>

Wrap POSIX FD functions in libroot_build

This makes opening symlinks work universally in the build system tools.
Two mechanisms have been implemented, both of which don't always work.
The first is remapping via preprocessor macros. This fails where equally
named methods are used (e.g. STL fstream::open()). The other is using
hidden functions in the new libroot_build_function_remapper.a that is
linked into everything that is linked against libroot_build.so. This one
fails for functions that are defined inline in headers (Linux/glibc does
that). Together they seem to cover our build system needs ATM.


# 55bc371993f0588118e3c684e18eae5b6e4a6e22 30-Jun-2011 Ingo Weinhold <ingo_weinhold@gmx.de>

Wrap POSIX FD functions in libroot_build

This makes opening symlinks work universally in the build system tools.
Two mechanisms have been implemented, both of which don't always work.
The first is remapping via preprocessor macros. This fails where equally
named methods are used (e.g. STL fstream::open()). The other is using
hidden functions in the new libroot_build_function_remapper.a that is
linked into everything that is linked against libroot_build.so. This one
fails for functions that are defined inline in headers (Linux/glibc does
that). Together they seem to cover our build system needs ATM.


# 4dbc2457985f94d2aa46668739f73231b4b2edfb 30-Jun-2011 Ingo Weinhold <ingo_weinhold@gmx.de>

Wrap POSIX FD functions in libroot_build

This makes opening symlinks work universally in the build system tools.
Two mechanisms have been implemented, both of which don't always work.
The first is remapping via preprocessor macros. This fails where equally
named methods are used (e.g. STL fstream::open()). The other is using
hidden functions in the new libroot_build_function_remapper.a that is
linked into everything that is linked against libroot_build.so. This one
fails for functions that are defined inline in headers (Linux/glibc does
that). Together they seem to cover our build system needs ATM.