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.
This should have been done along with the time_t change, but I forgot
to check this then.
Technically this breaks ABI against BeOS, but:
1. BeOS used an int32, so we'd already slightly broken ABI here
2. Only one thing at HaikuArchives (VMwareAddons) and one recipe at HaikuPorts
(samba) uses this function at all.
If it turns out some critical BeOS app uses this, then I guess we can enclose
GCC2 guards around it, but since I can't find any evidence of that, I'm
pushing it without them for now.
The only thing of any real use in this directory was the Be Newsletter
article, and the objdump from BeOS R5 (at least I guess that's what it is...)
so I kept those.
Augustin Cavalier