On 5/22/20 7:33 PM, Rich Felker wrote:
> On Fri, May 22, 2020 at 06:50:06PM +0200, Harald Welte wrote:
>> Hi Rich,
>>
>> On Thu, May 21, 2020 at 05:49:48PM -0400, Rich Felker wrote:
>>>> According to the OpenWRT build I have been provided by a 3rd party, it's
>>>> using musl-1-1.23.
>>>
>>> Can you confirm this to make sure we're not debugging an issue that's
>>> long since fixed? Run /lib/ld-musl-armhf.so.1 as a command and it will
>>> print its version.
>>
>> *sigh*. It was 1.1.20.  This specific (vendor) OpenWRT tree was broken in that
>> it used the 1.1.20 source code but called the generated packages and
>> path names 1.1.23 :/
>>
>> After updating the sources to actual 1.1.23, the constructor order is
>> correct and I can run the unmodified libraries + application just like
>> on glibc.
>>
>> Sorry for the noise then.  Normally if something is named 1.1.23 you
>> assume it also is 1.1.23 inside...
> 
> OK, I'll inquire with OpenWRT about what's going on here..
> 
Hi,

Hauke here form OpenWrt, I am just reading this. ;-)

OpenWrt never shipped musl 1.1.20 or 1.1.23 in any final release.
OpenWrt 19.07 uses musl 1.1.24
OpenWrt 18.06 uses musl 1.1.19
I also checked that this is really using this version and not just
claims to do so.

I assume that some vendor forked a random OpenWrt master state and had a
problem with their broken application and "fixed" it by downgrading
musl, but they only changed the git commit hash which should be used
and not the version number.

I saw that lynxis just send this patch to use the official tar.gz for
musl and not check musl out from git any more, I assume this is related
to this discussion:
https://patchwork.ozlabs.org/project/openwrt/patch/20200522153626.1398980-1-lynxis@fe80.eu/

Hauke