[OpenWrt-Devel] [PATCH] toolchain: musl: update to 1.1.22

[Koen Vandeputte]

On 12.04.19 17:04, Roman Yeryomin wrote:
> On 2019-04-12 17:39, Koen Vandeputte wrote:
>> On 12.04.19 16:32, Roman Yeryomin wrote:
>>> Compile and run tested on mt7621 and ar71xx
>>>
>>> new features:
>>> - priority-inheritance mutexes
>>> - membarrier syscall, pre-registration to use it, fallback emulation
>>> - header-level support for new linux features in 4.19, 4.20, 5.0
>>>
>>> major internal changes:
>>> - complete, async-safe view of all existent threads as global list
>>> - robust __synccall based on new thread list
>>> - new dynamic TLS is installed synchronously at dlopen
>>> - TLSDESC resolver functions no longer make bad ABI assumptions to 
>>> call C
>>> - resolved shared library dependencies are now recorded
>>>
>>> compatibility & conformance:
>>> - dependency-order shared library constructor execution
>>> - sigaltstack no longer rejects SS_AUTODISARM, future flags
>>> - FILE is now a complete (dummy) type in pre-C11 feature profiles
>>> - setvbuf reports failure on invalid arguments
>>> - TSVTX is exposed unconditionally in tar.h
>>> - multithreaded set*id() no longer depends on /proc
>>> - key slot reuse after pthread_key_delete no longer depends on /proc
>>>
>>> bugs fixed:
>>> - failures in multithreaded set*id() with concurrent thread 
>>> creation/exit
>>> - interposed free was called from invalid/inconsistent contexts
>>> - freeaddrinfo performed invalid free of some partial results lists
>>> - dlsym dependency order search had false negatives and false positives
>>> - dn_skipname gave wrong results for labels with 8-bit content
>>> - dcngettext clobbered errno, often breaking printing of error messages
>>> - sscanf read past end of buffer under certain conditions (1.1.21 
>>> regression)
>>> - pthread_key_create spuriously failed under race condition (1.1.21 
>>> regression)
>>> - fdopendir wrongly succeeded with O_PATH file descriptors
>>> - gets behaved incorrectly in presence of null bytes
>>> - namespace violations in c11 tsd and mutex function dependencies
>>> - incorrect prototype for makecontext (unimplemented)
>>>
>>> arch-specfic bugs fixed:
>>> - s390x had wrong values for POSIX_FADV_DONTNEED/_NOREUSE
>>>
>>> Signed-off-by: Dainis Jonitis <dainis.jonitis at ubnt.com>
>>> Signed-off-by: Roman Yeryomin <roman at advem.lv>
>>> ---
>>>   toolchain/musl/common.mk | 6 +++---
>>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk
>>> index b52263c43b..ae7758e8b5 100644
>>> --- a/toolchain/musl/common.mk
>>> +++ b/toolchain/musl/common.mk
>>> @@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk
>>>   include $(INCLUDE_DIR)/target.mk
>>>     PKG_NAME:=musl
>>> -PKG_VERSION:=1.1.21
>>> +PKG_VERSION:=1.1.22
>>>   PKG_RELEASE:=1
>>>     PKG_SOURCE_PROTO:=git
>>>   PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
>>> -PKG_SOURCE_VERSION:=1691b23955590d1eb66a11158fdd91c86337e886
>>> -PKG_MIRROR_HASH:=4fa312d0ca020d31603ced84a7103fb328c6ae9508239491a228be17e7807147 
>>>
>>> +PKG_SOURCE_VERSION:=e97681d6f2c44bf5fa9ecdd30607cb63c780062e
>>> +PKG_MIRROR_HASH:=a6655418698735e19fe1c2deffb7335bbda634385c636206dd3cd5c8194a3ce0 
>>>
>>>   PKG_SOURCE_URL:=git://git.musl-libc.org/musl
>>> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
>>>
>>
>> Thanks for the patch, but:
>>
>> 2 comments:
>>
>> - I've already got it in my staging tree [1]
>
> That's a strange one, making me feel like I should look into every 
> existing staging tree/branch before I send a patch :)
>
Seems like we simply hit a race condition here which luckily is pretty rare.
>> - The custom patches are not refreshed here (see my commit)
>
> True, didn't notice it needs a refresh.
>
>>
>> I can add your SoB's (or Tested-by's) in mine if you like?
>
> Well we did test it and Dainis was an original author of few fixes there.
> But that's ok, you first, do whatever you think is ok.

It seems fair to me to add you guys to the patch :-)

done.


>
>
> Regards,
> Roman
>
Thanks again for the effort in sending it over :)

Koen


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel