Re: [musl] MUSL ignores__attribute__((constructor(priority))) ?

[Rich Felker <dalias@libc.org>]

On Fri, May 22, 2020 at 07:45:48PM +0200, Hauke Mehrtens wrote:
> 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/

Thanks for the quick follow-up!