Following recent changes to use libroot_build on Haiku also, it is now
actually impossible to build Haiku components on non-Haiku platforms
(BeOS R5, Dan0, BONE, Zeta), so we can remove any logic related to this.
This is only the first part; still to be removed are:
* SetSubDirSupportedPlatformsBeOSCompatible
* HOST_PLATFORM_BEOS_COMPATIBLE
* TARGET_PLATFORM_BEOS_COMPATIBLE
As it turns out, using the xattr emulation layer plus "libgnu"
causes some strange mixups at package build time, and so packages
built with it were winding up with no attributes at all.
So I've just bitten the bullet and written a full passthrough layer
to the system attributes. Verified using a full build of haiku.hpkg
this time ... after a lot of painful debugging of symlink mixups.
Hopefully I am finally rid of this plague...
To quote jscipione (from 95e8362c52),
"Let me tell you a story about a bug" -- though this tale spans a much
lesser time than that one did.
In 5e19679ea3, I enabled libroot_build for
Haiku, instead of using the system libroot as we had before. There were
a number of bugs introduced along with this that I hadn't fixed (and there
may be more after this), but most of the obvious ones (crashes on x86_64...)
were fixed shortly enough.
Attribute usage, though, was a different story. Unlike most of the POSIX
calls in libroot, which were aliasing system functions no matter what the
platform, the attribute calls were not, as they are specific to Haiku.
Initially I had completely forgot about them, and it wasn't until a few days
later when I noticed that I had an "attributes" directory in my generated
that I realized that the "generic" attribute layer was being used on Haiku.
I attempted a fix for this in 5e19679ea3,
thinking that would clear the problem up, but I didn't actually run a test
beyond seeing that my BuildConfig had been updated properly. In fact,
BuildSetup was hard-wired to not even pass that definition through on
Haiku, and so that commit had in effect caused nothing.
My initial "fix" of just changing BuildSetup then caused a build failure,
as while libroot_build itself compiled, it ran into errors whenever attributes
were used, because in letting the real libroot's attribute calls shine
through, I had bypassed libroot_build's FD emulation/shim layer.
Then I tried and failed at three separate attempts to solve this with code:
- a version of the "fs_attr_...h" interface for Haiku. This proved possible
in theory, but in practice I would need to reimplement a lot of attribute
handling code in it, because all I had access to from there was syscalls.
- a version of "fs_attr_untyped" that bypassed its reimplementations of
the "fs*attr" functions for the libroot ones, only using the FD shim layer.
This proved possibly not even theoretically possible because it would have
caused preprocessor hell in some of the build headers, and also assumptions
about how attributes are read were totally different.
- a completely new "fs_attr_haiku" that was a completely new interface to
the fs*attr functions. This proved practically impossible because of the
need to include structures from the system libroot to call out to readdir,
etc. that attempts to solve would also have caused preprocessor hell.
Then I realized that the Linux xattr emulation library, which I'd used
as a reference when attempting the first solution, was shipped by default
as a system library in all builds of Haiku ... and so I could just tell
fs_attr_untyped to use the Linux xattr handler, and then link against libgnu.
So that is how I arrived at this strange and decidedly unorthodox solution
to a problem of my own creation.
Not in the POSIX specification, but defined (not behind any guards)
in (at least) FreeBSD, NetBSD, glibc, and macOS.
Found by miqlas and myself while working on porting GNU inetutils.
I've updated the docs to match the current BMailComponent, documented
new functions, and cleaned up the MailComponent.h file to at least
somewhat match our coding style.
First in a series (there are 3 more old API docs on the Mail Kit in that
"Public API" folder.)
It was needed on macOS for a time when BUrl used regexes for parsing.
Now it does not, and so we can remove libshared's RegExp from build
libshared, and thus also libgnuregex.
The Interface Kit is long since "99% functional", so lists of modules
with what's-implemented-what's-not are not really helpful anymore.
The one (rather lengthy) file describing the unit testing system
set up by the IKTeam is indeed useful, so keep that.
Previously when we used Drupal, the icon guidelines there "shadowed"
the ones in this tree. Now that the git-based website reigns supreme,
we should not keep two copies around. I've chosen to preserve
the one in the website repository and trash this one because the icon
guidelines primarily target artists, not programmers (as just about
all other docs in this directory do.)
Previously I had intended to take the simpler route and just lock the
already-inserted team before setting the io_context (as in prior commits),
but after hearing some reports from users that some other seemingly
unrelated KDLs had possibly cleared up after the first iteration of
that fix, I decided to go with this route instead.
Now we do not insert the team into the parent and hash and send the
notification until just before the team's main thread is actually started;
i.e. we now initialize not only io_context but also the team's args, VM
address space, and user data (and if creation of any of these fails
we do not inset the team into the hash at all.)
Since the team structure was not locked at all while this initialization
was taking place, any number of race-dependent bugs could have been
caused by this on multicore systems.
The KDL in #13861 was apparently caused by a NULL io_context. I read over
the Team code and have applied the following fixes here as a result:
1. A NULL io_context is entirely possible, as implied by the NULL check
before deinitializing it in Team's destructor, so account for that.
2. Team objects have a class-wide lock which must be acquired before
directly accessing class members, so use that here.
First part of the fix for #13861.
Implemented by just not defining the functions at all and letting
the Haiku ones shine through. In the future, though, we should wrap
them properly.
(Between the switch to libroot_build and this commit, libroot_build
was using the generic attribute emulation layer on Haiku ... whoops.)
I didn't notice this in the previous commit because apparently GCC2
just links against libroot's versions of them. On GCC5, however,
the version from libroot_build was used even for calls from libroot itself,
which led to infinite loops and then stack overflows.
So instead we must have the "syscall" functions in libroot_build shadow
the real ones by being named differently, which I did by changing their
prefix from "_kern" to "_kernbuild" via preprocessor macros.
Since the build syscalls.h is now substantially different than the non-
build one (and has not been synchronized in nearly a decade anyway),
I've just stripped out all the syscall defns except for the ones actually used
in the build.
Thanks to kallisti5 for helping me debug and test.
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).
Technically a "hack" (but then again most of the config/build stuff is);
as we need to use the system's config/types.h in order to get stdint
definitions and the like.
Previously there was a config_build directory which allowed the existence
of two types.h -- the system one, and the headers/build one, but seeing
as we only need this to provide Haiku-specific core types on other platforms,
using the system's one should be fine.
Our core type definitions have not changed in some time (and it's unclear
when they would change aside from potential new platforms), breakage of the
Haiku-on-Haiku build due to this should not happen often (if ever.)
Since it's just a C compiler "technically" the ABI does not matter,
but since it also can target other ABIs from one toolchain (e.g. x64),
just treat it as GCC4 ABI unilaterally.
Fixes#13847.
Now that we do not target BeOS and also do not include the main headers
directory when building "build" binaries, we can drop the separate
config_build directory and thus also the separate BeBuild.h, and just
..-include the regular one.
The build BeBuild.h defined empty _IMPEXP_ROOT and _IMPEXP_BE preprocessor
macros that the regular one does not; so I also re-synchronized
headers which used these as needed.
Tracker uses KeyInfos.h from it. Previously this wasn't needed
due to the SEARCH_SOURCE added in the Shortcuts preferences,
but as that is now just a UseHeaders, we need it here (if only
for the DoCatalogs.)
This file was apparenly based off the BeOS one (as is evidenced
by the "Be Incorporated" copyright ... which is problematic.)
Now it's directly based off of the non-build one.
The previous commit only checked that they worked if the user
enabled them, but now they will be enabled automatically if the
underlying filesystem supports them.
The ReadMe.Compiling has been updated accordingly.
Previously the helptext just displayed a warning to "make sure your
file system supports sufficient attribute sizes", and left the
actual checks to libroot_build at runtime.
Now we use the native command-line tools of each platform to make sure
that we can actually set attributes large enough for --use-xattr and
--use-xattr-ref respectively.
Previously --update was kind of a hack, as it just dumped all
the variables from BuildConfig back into ./configure and attempted
to rerun from there.
Instead, now we store all of the variables and environs configure
was invoked with in the top of BuildConfig and re-call it using them.
This is much more robust, as configure will actually recompute
all of the values from the BuildConfig.
As a side effect, if configure was originally invoked to build crosstools,
it would have done so again, so instead add a check to see if they
exist, and skip them if they do. It's easy enough to delete the
directory if you want to force a crosstools rebuild.
Briefly discussed with mmlr on IRC.
The base VMCache class changed to the generic_ types with their
introduction in in *2011* (435c43f591),
but these classes were never properly adapted. These functions should not
be called here (they panic() -- but the base class only returns B_ERROR,
so that is a difference at least.)
Found by Clang's -Woverloaded-virtual.
Instead build the one in-tree from src/data/package_infos/. Fixes the
"HaikuPorts repos have wrong URL" problem that has occured since the
switch to buildmaster repos.
When compiling with GCC, these headers get pulled in from the
gcc_syslibs_devel package, but we cannot do something similar
for Clang as Clang adds/removes internal builtins used by
the headers nearly every version. So instead we just copy
all the intrinsics headers from current Clang into generated,
and make sure this directory is included before any others.
That requires more padding (1 byte vs 4 or 8 depending on integer size),
so just use regular loops and chained ==s.
Caught by Clang. No functional change intended.
* Actually locate the clang executable, and allow user overrides
* Properly preserve arguments in get_build_tool_path
* Fix get_build_tool_path for commands with dashes (e.g. "clang-5.0")
* Hashing semantics for the new build repositories are different than
the old ones, so update those (if the x86 build was not broken before
it is now...)
* OptionalPackages has been updated slightly (removed libtool and git_cvs
from the default images, as they are rarely used nowadays and would pull
in a bunch of dependencies we don't really care for either)
* Removed lib:libqrencode from Haiku package requires (qrencode_kdl is a
static library, the userland libqrencode is not used anywhere in the tree,
as far as I can tell)
* Fix build of JPEG2000 translator after update
* Decouple fluidsynth build machinery and remove from image now that it
is no longer used
* Update repository URL in Repositories preflet
x86 is unaffected, as already mentioned. This breaks the build,
but since this diff was large, I wanted to have the functionality
changes be clear, so they are in the next commit.
This is essentially the replacement for "jam upload-packages" --
it goes through a directory of packages (intended to be one made by
buildmaster), picks the packages out of it that are in the repository
file passed to it, and then hardlinks them to a second directory
as well as updates the repository file and creates a package_repo.
This is what was used to mass-modify the repository files which
will be updated in the next commit.
The packages that remain are only the ones used somewhere in Jam
(including ones off by default, e.g. Wonderbrush, Live555.)
The x86 repo is untouched as it is being phased out and has no buildmaster-
generated equivalent.
It was trying to use $(feature:U) outside of the loop where it is
actually set. Thanks to PulkoMandy for spotting the problem.
(How did this not break tons of stuff?)
* Actually set status before testing it
* sscanf (reads from passed buffer) not scanf (reads from stdin)
* &httpStatus not httpStatus.
Found by Coverity.
Under normal conditions this will behave identically. But when using LD_PRELOAD
or the like, some shared objects (and dependencies) are loaded before the
app image is, and on the secondary arch on hybrid builds, will fail to load
any of their dependencies due to sSearchPathSubDir not being set.
Fixes#12214, which had plagued users of libroot_debug for a long time now.
At present, does not work (it fails to properly set up interrupts,
resulting in thousands of unhandled ones which all but grinds the system
to a halt) but this at least is some progress.
Augustin Cavalier