Prior to hrev47631 (2014), HAIKU_TOP was relative when jam was invoked
from the repository root, and not relative when jam was invoked from
any other location, including "generated." In hrev47631, Jamrules
was changed to be as it was before this commit, in order to fix#11101
(Haiku repository creation failed due to the use of relative paths.)
GCC, however, injects the full path passed to the compiler into some
symbols under certain circumstanes (anonymous namespaces, for one),
and so a relative path for more reproducible builds is preferred.
It seems the aforementioned bug is no longer with us, as a full image
build that I did with this change worked just fine.
Note that you will have to run "configure --update" after this
in the case that you usually invoke "jam" from the generated directory,
as the Jamfile configure generated included absolute paths. (The reminder
to do that this diff includes can be removed after some reasonable amount
of time.)
OpenJDK 1.8 somehow manages to trigger this. Before this commit it would
just attempt to read past the end of the vector, which of course segfaulted,
which seems to imply nobody has run into this case before.
Using BDateFimeFormat avoids going through libroot and up again to ICU
throuhg the locale add-on. Moreover, it uses the Locale settings
directly instead of relying on the LC_* environment variables.
Fixes day names in Web+ history menu always showing in english. Tnaks to
Oco for noticing!
Change-Id: I0c7f321a6147e8f5ab31f82de836c5ad23bb321b
Reviewed-on: https://review.haiku-os.org/650
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
FreeBSD's "ticks" has a granularity of whatever "hz" is, presently 1000.
It's declared as "extern int32" in FreeBSD's codebase, as it's the
defining unit of time for most operations.
We just use system_time() for essentially the same purpose, which requires
no hard-clock timer interrupts at all, and so Colin seems to have decided
to emulate "ticks" by just triggering a timer once per millisecond and then
incrementing the "ticks" variable.
1000 timer interrupts per second is quite a lot (assuming the kernel
actually combined these between drivers, otherwise it would be 1000
*per driver*), and probably a contributor to Haiku's not-so-great
battery performance on most laptops.
The next commit will make it a "#define" instead of an "extern".
I've already submitted this for upstream inclusion in FreeBSD.
Sorry for the noisy diff with all the whitespace changes...
sRandomLock is a driver-global lock used by all instances of the "random"
device, of which there can be more than one, it seems; and somehow some
are destroyed before others. I didn't really investigate too far to see
under what circumstances that occurs.
Found while trying to compile some ports; suddenly all attempted
reads of /dev/random started PANIC'ing with "mutex uninitialized".
It seems GCC2 occasionally will inline a call to memcpy with
a count of 0, which this function did not previously expect
and would result in a "Divide Error Exception."
Hopefully fixes#14613.
* Initialize "status" to B_NO_INIT, which will skip the main 'if'
the first go-around and go straight to the acquire_sem_etc(),
as we will have be invoked from the callout initializer, and so
there will of course be no callouts.
* Actually check the return code of mutex_lock, and do another loop
iteration (which skips this main 'if' as status will not be one
of those things.)
* Correct failure deinitialization order in init_callout().
* Destroy the mutex after the worker thread exits (this is the real fix.)
Fixes#14660, and other "hang on cursor" / "hang on black screen" /
or possibly even a "hang on rocket" introduced in yesterday's builds.
DeleteChains() needs the chain locks and domains, so those need to
be uninitialized after them. This now matches the constructor's
deinitialization order.
Fixes a panic exposed by the previous commit.
Previously, there were a number of circumstances where these were
not getting reset properly, leading to some destroyed mutexes having
holders of the last thread which locked them, and some with "-1",
which meant that the next call to "mutex_lock" just behaved as if
the lock was still valid (!), and so the unlucky caller would deadlock
forever.
Now we properly reset these fields, which means from now on attempts to
lock or unlock destroyed mutexes will lead to "PANIC: uninitialized mutex"
on KDEBUG kernels, and (as before) an infinite deadlock on non-KDEBUG
kernels (perhaps we should store the thread_id of the locker on non-KDEBUG
kernels also?).
As the next commits will show, this already uncovered a number of bugs,
and there are of course potentially more strange deadlocks caused by this.
* We're making the assumption about EFI here, but it's
fine since those defines will just go unused on non-efi builds.
* Jam segfaults when we get two for's, a case, and an if deep.
(adding an x86_64 check to efi section just below)
Change-Id: Id98e87b6570ddc7d9c2195cd05b0526e71771675
Added subsystem_vendor_id and subsystem_id for iMac 24 inch early 2008 (iMac 8,1) and Macbook Pro 3,1 with specific quirks for those systems. This enables sound via head phone out at a decent level and quality. Previously, sound with the Haiku HDA driver was distorted and very low
Change-Id: I8e3dc3dbf5324bafff2b35ae64b43a0088272c8d
Reviewed-on: https://review.haiku-os.org/647
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Use delete[] instead of delete, since memory is allocated by new[]
at line 139.
Pointed out by clang.
Change-Id: I70396283b8d2c01d52886f7543804998d891ea44
Reviewed-on: https://review.haiku-os.org/646
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Some packages have excessively long copyright labels that were forcing
the HaikuDepot window to become too wide. So in this case, put the full
copyright string in the tooltip, and only the first 45 characters in
the label.
As discussed in #14598, there are now two tabs instead of the
checkbox: "Featured packages" and "All packages". It otherwise
behaves as before.
Also fixes#12428.
Currently using the LEGACY_TX path as the newer one requires mtx_trylock()
and "curcpu", which I haven't implemented yet.
Completely untested as I don't have this hardware.
* init_hardware is unnecessary and mostly a duplicate of init_driver;
so just remove it in favor of that.
* Deduplify some of the _DRIVER macros as possible
* Don't include net_stack.h, we don't need it here; and fix
callout.h following that.
Technically the profile is supposed to be sourced, but it seems that
some scenarios / applications do not do this and instead run it.
Before the recent changes to PS1, it was also exported, and now
it is again. Should fix entering HaikuPorter chroots under the new profile.
Also renamed "ARCH" to "_ARCH" to better accomodate those
who are sourcing this file, in case they want to pass a variable
named ARCH through.
* Fixed colour localization on test page
* Changed JobListView to use plural placeholders
* Changed PrintersWindow to use placeholders
Change-Id: I39477351364a0182cf629476de767af18f9c0d61
Reviewed-on: https://review.haiku-os.org/524
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
