gcc 5.1 doesn't define char16_t and char32_t (unless in C++ mode),
causing compile failures.
Change-Id: I08dcd13cdf8cd59a4a2f191864bedf4c0d1bb313
Signed-off-by: Bernhard Rosenkränzer <Bernhard.Rosenkranzer@linaro.org>
Changes affecting future time stamps
Egypt's spring-forward transition is at 24:00 on April's last Thursday,
not 00:00 on April's last Friday. 2015's transition will therefore be on
Thursday, April 30 at 24:00, not Friday, April 24 at 00:00. Similar fixes
apply to 2026, 2037, 2043, etc. (Thanks to Steffen Thorsen.)
Changes affecting past time stamps
The following changes affect some pre-1991 Chile-related time stamps
in America/Santiago, Antarctica/Palmer, and Pacific/Easter.
The 1910 transition was January 10, not January 1.
The 1918 transition was September 10, not September 1.
The UTC-4 time observed from 1932 to 1942 is now considered to be
standard time, not year-round DST.
Santiago observed DST (UTC-3) from 1946-07-15 through 1946-08-31,
then reverted to standard time, then switched its time zone to
UTC-5 on 1947-04-01.
Assume transitions before 1968 were at 00:00, since we have no data
saying otherwise.
The spring 1988 transition was 1988-10-09, not 1988-10-02.
The fall 1990 transition was 1990-03-11, not 1990-03-18.
Assume no UTC offset change for Pacific/Easter on 1890-01-01,
and omit all transitions on Pacific/Easter from 1942 through 1946
since we have no data suggesting that they existed.
One more zone has been turned into a link, as it differed
from an existing zone only for older time stamps. As usual,
this change affects UTC offsets in pre-1970 time stamps only.
The zone's old contents have been moved to the 'backzone' file.
The affected zone is America/Montreal.
Bug: 20287125
Change-Id: I8512c4e9ab09725395b256aba59ca34a23d1c995
The visibility control in pthread_atfork.h is incorrect.
It breaks 64bit libc.so by hiding pthread_atfork.
This reverts commit 6df122f8528f9b9fcf7dfea14ae98b0ef66274e1.
Change-Id: I21e4b344d500c6f6de0ccb7420b916c4e233dd34
This doesn't affect code like Chrome that correctly ignores EINTR on
close, makes code that tries TEMP_FAILURE_RETRY work (where before it might
have closed a different fd and appeared to succeed, or had a bogus EBADF),
and makes "goto fail" code work (instead of mistakenly assuming that EINTR
means that the close failed).
Who loses? Anyone actively trying to detect that they caught a signal while
in close(2). I don't think those people exist, and I think they have better
alternatives available.
Bug: https://code.google.com/p/chromium/issues/detail?id=269623
Bug: http://b/20501816
Change-Id: I11e2f66532fe5d1b0082b2433212e24bdda8219b
According to runs on /system/lib there using
unsigned leb128 does not save us any additional
space. In order to keep packing as simple as
possible switch to using signed leb128 for
everything.
Bug: http://b/18051137
Change-Id: I1a47cb9eb2175895b3c3f7c13b4c6b1060de86c0
Prebuilt shared libraries (libclang.so, libLLVM.so and etc) have been
moved to prebuilts/sdk/tools/linux/lib64. Update the search path in
cpp.py to match the change.
Bug: 20485471
Change-Id: Ib7784db4d5529d16a1e2bfc07cb0237929bc5a64
Statically link libc++ to relocation_packer in
order to make it work from prebuilts
Bug: http://b/18051137
Change-Id: I933ed6a0e48780a26b261069eb6a293432824fe7
