These are now done in AcpiInitializeSubsystem(), as part of the
early init so they can be present when the tables are loaded.
Should fix ACPI not working since the merge.
Requested by RudolfC. Apparently there was a regression which prevented
ACPI battery/power from working on his system, which was fixed by
https://github.com/acpica/acpica/commit/a3267967c.
The only testing I did with this was confirm it compiles and boots
in a VM, so apologies if this breaks something else.
The heap implementation of the runtime_loader was switched to the one
of the bootloader in 6f0994d but was since updated independently.
To keep the diff between the two implementations as small as possible,
the bootloader implementation was first copied to the runtime_loader
and then some features not relevant in the runtime_loader (like the
special large allocation handling) have been removed and the
runtime_loader specific features (grow_heap, add_area) have been
reintegrated. But basically this applies 96689a5..HEAD of
src/system/boot/loader/heap.cpp to the runtime_loader heap.
This brings in the switch from a linked list to a splay tree based
free chunk management. Since the allocation counts in the runtime_loader
are rather small, this does not perceptibly affect performance in either
direction though.
The needed storage space for tracking the allocation size was not
accounted for when growing the heap. Since the growth size is always
rounded up to a multiple of 32KiB, this did almost never matter as the
new allocation wouldn't need the full size. If the allocation did
happen to need the full size however, the newly added area would always
be too small. As the allocation attempt was simply restarted after each
successful growth, this lead to an endless loop creating small new
areas, which would then quickly starve the system for memory.
Haiku does not yet support certain features related to POSIX threads.
Constants used to test for the presence of these features should
therefore be left undefined, according to the POSIX spec, but are
currently set to -1. This can cause software built on Haiku to
incorrectly detect the presence of these features.
* unistd.h: Undefine _POSIX_THREAD_ATTR_STACKADDR,
_POSIX_THREAD_PRIORITY_SCHEDULING feature constants.
* conf.cpp: __sysconf: Return -1 for unsupported features.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
This code is closer to what we used before for gcc2, and should not
crash there anymore. I could not get exactly the same code to work, but
reduced the difference to a single statement (which makes gcc2 work and
breaks gcc4). This is protected under a guard with appropriate ffmpeg
version test.
This code works for both gcc2 and gcc4 (tested with mp3 and aac files as
well as youtube videos). It still gets the timestamps wrong with ffmpeg
2.4, but I'll try to solve that another time.
Commit 856cc59e58 didn't really "fix"
anything; it just broke audio pretty much everywhere but YouTube,
and there videos play at 2x speed so it wasn't really worth it.
Stopgap solution for #12509.
* update gmp package for x86, gmp_x86 for x86_gcc2.
* update wget packages for x86 and x86_gcc2.
* update icu* packages for x86_gcc2 and x86.
* update libgpg_error* packages for x86_gcc2.
* Beware that installing these packages will replace gcc and syslibs. gcc5 packages
can be used to check that packages still build correctly with gcc5, simply being
places in haikuporter packages folder.
* libstdc++ is configured for "gcc4 compatibility", this means we could switch to
this version, while maintaining binary compatibility. However a switch to the new abi
will eventually require a full rebuild of packages depending on libstdc++. For this
to happen, the affected packages should be buildable with gcc5, which can easily be done
with the addition of these packages. Mainstream packages with up to date versions are
probably already buildable with gcc5, some aren't (ie boost). All haiku-* packages are
to be checked. I'll open a provisioning ticket to track the related activities.
