Reduce duplication of code by
* Removing from elf_common.h definitions available in os/kernel/elf.h
* Deleting elf32.h and elf64.h
* Renaming elf_common.h to elf_private.h
* Updating source to build using public and private ELF header files
together
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Make a version of elf.h (assembled from the private header files
elf_common.h, elf32.h and elf64.h, and including Haiku's extensions for
C++) available to applications ported from UNIX.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
* Services that end are now automatically restarted.
* However, this is very basic at the moment, there is no throttling,
and no support for shutting down the system.
* Ie. a listing of all targets/jobs, as well as specific (basic) info
on each.
* Also added a bit of optional debug output.
* Moved translating the path to launch time -- we should take the job's
environment into account here at some point.
Also print the locker sem (for manual name lookup) and the involved
threads. It was also missing the line terminator which messed up the
following output.
Also fix a typo in a comment.
Since a BLocker can be unlocked from other threads than the one holding
the lock, it can also be further unlocked even when already unlocked.
This caused the recursive count to become negative. The first lock then
needs to reinitialize the count to 1 for the lock balance to work again.
Just incrementing the negative recursive count lead to it never
counting back down from one to zero in the unlock case, which made the
BLocker impossible to unlock.
This makes the Haiku BLocker behave exactly like the BeOS one, including
the negative recursive count and reinitialization, as evidenced by its
debugging features showing the internal counts.
Alternatively to reinitializing the recursive count it could be
prevented from going below zero in the first place, but I don't see why
we should deviate from BeOS there while allowing its awkward unlock
behaviour.
This makes some more exotic use cases work like the BGLView <-> SDL
combination that previously would always just hang. While these abuses
should be reviewed/corrected, just hanging the BLocker doesn't seem
useful.
This was added in hrev47174 but isn't needed. (confirmed with jessicah)
the -e flag was causing the script to exit when it encountered an error
instead of allowing us to print an error message and exit ourselves.
I accidentially tried to compile Haiku on a case-insensitive FS and
tripped over this.
The configure script should print an error message if you try to configure
on a case-insensitive FS once again.
This adds to the "unittests" target a dependency on the
"AppTestRunApp3a" (etc.) files meant to be copied as part of the
BApplication test suite so they are generated when "jam unittests" is
run.
* TestsRules: Add "UnitTestDependency" rule.
* testapps/Jamfile: Make unit tests depend on copied files.
Fixes#12441.
Signed-off-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Having to upload the 650+ MiB source package with every new version is a drag.
People interested in the code can get it directly at
https://github.com/haiku/webkit/releases
* There is a small API change, and only the x86_gcc2 package was
updated. This means the x86 and x86_64 builds are broken until someone
updates the packages.
* Fix several small bugs, the most important one being that cookies are
written to disk again.
The use of an unreliable test for relocatability effectively broke
runtime_loader's support for non-position-independent executables, as it
would insist on randomly positioning these files' segments in memory
anyway causing the program to quickly crash.
With this change runtime_loader uses the object type specified in the
file's header to determine whether its segments can be safely relocated,
restoring support for non-PI executables.
Fixes#12427.
Signed-off-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* Add -fgnu89-inline flag for libroot/posix/glibc
* Change __GNUC__ == 4 to __GNUC__ >= 4
Signed-off-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Fixes#11990, most of the changes had already been done.
Several errors in the html output caused WebPositive to not render
the file completely.
Signed-off-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Fixes#12387.
While the game is pure python and packaged for any architecture, the
engine (FIFE) is C++ with python binding via swig, making the game
only installable on x86 and x86_64. We'd need to provide a python_x86
to support secondary architecture python modules.
