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

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

[Harald Welte]

Hi all!

While investigating some really strange behavior of osmocom software
on MUSL based systems (see https://osmocom.org/issues/4456)
there are two observations:

1) if there are multiple libraries (in this example libosmocore and libtalloc,
   where libosmocore depends on libtalloc), the __attribute__((constructor))
   functions are not called in inverse dependency order, i.e. the talloc
   ones are *not* called before those of libosmocore.

2) even when adding an explicit "priority" field like
   static __attribute__((constructor(65535))) void on_dso_load_ctx(void)
   the MUSL ld.so doesnt' seem to respect this, i.e. it still calls the
   constructor with the high priority value *before* the constructor of lower
   priority.  This is not as specified in https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Function-Attributes.html

I don't know whether '1' is a bug (i.e. whether it is valid to assume constructors
of libraries are executed in-line with library dependencies).   However, I am
quite convinced '2' is a bug.

Regards,
	Harald

p.s.: Please keep me in Cc, I'm not a subscriber to this list.

-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

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

[Rich Felker]

On Thu, May 21, 2020 at 10:22:53PM +0200, Harald Welte wrote:
> Hi all!
> 
> While investigating some really strange behavior of osmocom software
> on MUSL based systems (see https://osmocom.org/issues/4456)
> there are two observations:
> 
> 1) if there are multiple libraries (in this example libosmocore and libtalloc,
>    where libosmocore depends on libtalloc), the __attribute__((constructor))
>    functions are not called in inverse dependency order, i.e. the talloc
>    ones are *not* called before those of libosmocore.

They should be, since commit 188759bbee057aa94db2bbb7cf7f5855f3b9ab53
(releases 1.1.22 and later). Are you using an older version?

> 2) even when adding an explicit "priority" field like
>    static __attribute__((constructor(65535))) void on_dso_load_ctx(void)
>    the MUSL ld.so doesnt' seem to respect this, i.e. it still calls the
>    constructor with the high priority value *before* the constructor of lower
>    priority.  This is not as specified in https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Function-Attributes.html
> 
> I don't know whether '1' is a bug (i.e. whether it is valid to assume constructors
> of libraries are executed in-line with library dependencies).   However, I am
> quite convinced '2' is a bug.

The scope of ctor priorities is within a single DSO. Priorities are
used by the linker to order them within the ctor array of the library.
They are not exported for dynamic linker to use, and trying to
interleave the calling of individual ctors/dtors between different
libraries would be really problematic I think.

In general, if you have specific order dependencies between ctors, the
best way to express that is with explicit calls from one library's
init function to the other using call_once/pthread_once. This is fully
portable and does not depend on implementation details.

> p.s.: Please keep me in Cc, I'm not a subscriber to this list.

Will do. Thanks for mentioning it.

Rich

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

[Harald Welte]

Hi Rich,

thanks for your super-fast response.

On Thu, May 21, 2020 at 04:40:49PM -0400, Rich Felker wrote:
> On Thu, May 21, 2020 at 10:22:53PM +0200, Harald Welte wrote:
> > 1) if there are multiple libraries (in this example libosmocore and libtalloc,
> >    where libosmocore depends on libtalloc), the __attribute__((constructor))
> >    functions are not called in inverse dependency order, i.e. the talloc
> >    ones are *not* called before those of libosmocore.
> 
> They should be, since commit 188759bbee057aa94db2bbb7cf7f5855f3b9ab53
> (releases 1.1.22 and later). Are you using an older version?

According to the OpenWRT build I have been provided by a 3rd party, it's
using musl-1-1.23.  I meanwhile also found that the ELF specifications
back to 1997 already specify that this ordering is required of a linker.

There clearly is no circular dependency either:

# ldd ./libosmocore.so
        ldd (0xb6f46000)
        libtalloc.so.2 => /usr/lib/libtalloc.so.2 (0xb6efd000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6ee2000)
        libc.so => ldd (0xb6f46000)

# ldd ./libtalloc.so
        ldd (0xb6f5b000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6f29000)
        libc.so => ldd (0xb6f5b000)

and the executable linking against both of them:

# ldd /usr/sbin/osmo-remsim-client-st2
        /lib/ld-musl-armhf.so.1 (0xb6eeb000)
        libosmogsm.so.13 => /usr/lib/libosmogsm.so.13 (0xb6e8d000)
        libosmoabis.so.6 => /usr/lib/libosmoabis.so.6 (0xb6e67000)
        libosmousb.so.0 => /usr/lib/libosmousb.so.0 (0xb6e53000)
        libosmo-simtrace2.so.0 => /usr/lib/libosmo-simtrace2.so.0 (0xb6e40000)
        libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0xb6e23000)
        libosmo-rspro.so.1 => /usr/lib/libosmo-rspro.so.1 (0xb6df3000)
        libtalloc.so.2 => /usr/lib/libtalloc.so.2 (0xb6ddc000)
        libosmocore.so.12 => /usr/lib/libosmocore.so.12 (0xb6daa000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6d8f000)
        libc.so => /lib/ld-musl-armhf.so.1 (0xb6eeb000)
        libosmovty.so.4 => /usr/lib/libosmovty.so.4 (0xb6d63000)
        libosmosim.so.0 => /usr/lib/libosmosim.so.0 (0xb6d43000)

(executed using the musl ldd on the target itself)

Still, I can show very clearly while stepping through [remote] gdb that
the constructor of libosmocore is called before that of talloc.

Also, here the 'readelf -d' output of the related objects:

$ readelf -d ./build_dir/target-arm_cortex-a8+vfpv3_musl_eabi/talloc-2.1.14/bin/shared/libtalloc.so.2

Dynamic section at offset 0x5dd4 contains 31 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so]
 0x0000000e (SONAME)                     Library soname: [libtalloc.so.2]
 0x0000000c (INIT)                       0x1d4c
 0x0000000d (FINI)                       0x4cf0
 0x00000019 (INIT_ARRAY)                 0x15dc8
 0x0000001b (INIT_ARRAYSZ)               8 (bytes)
 0x0000001a (FINI_ARRAY)                 0x15dd0
 0x0000001c (FINI_ARRAYSZ)               4 (bytes)
 0x00000004 (HASH)                       0xd4
 0x6ffffef5 (GNU_HASH)                   0x460
 0x00000005 (STRTAB)                     0xf18
 0x00000006 (SYMTAB)                     0x718
 0x0000000a (STRSZ)                      1981 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000003 (PLTGOT)                     0x15eec
 0x00000002 (PLTRELSZ)                   488 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x1b64
 0x00000011 (REL)                        0x1b1c
 0x00000012 (RELSZ)                      72 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffc (VERDEF)                     0x17d8
 0x6ffffffd (VERDEFNUM)                  23
 0x00000018 (BIND_NOW)
 0x6ffffffb (FLAGS_1)                    Flags: NOW
 0x6ffffffe (VERNEED)                    0x1afc
 0x6fffffff (VERNEEDNUM)                 1
 0x6ffffff0 (VERSYM)                     0x16d6
 0x6ffffffa (RELCOUNT)                   4
 0x00000000 (NULL)                       0x0

$ readelf -d ./build_dir/target-arm_cortex-a8+vfpv3_musl_eabi/libosmocore-1.3.1/src/.libs/libosmocore.so

Dynamic section at offset 0x1e938 contains 30 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libtalloc.so.2]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so]
 0x0000000e (SONAME)                     Library soname: [libosmocore.so.12]
 0x0000000c (INIT)                       0x844c
 0x0000000d (FINI)                       0x1b7f8
 0x00000019 (INIT_ARRAY)                 0x2e598
 0x0000001b (INIT_ARRAYSZ)               12 (bytes)
 0x0000001a (FINI_ARRAY)                 0x2e5a4
 0x0000001c (FINI_ARRAYSZ)               4 (bytes)
 0x00000004 (HASH)                       0xf4
 0x6ffffef5 (GNU_HASH)                   0x126c
 0x00000005 (STRTAB)                     0x44f8
 0x00000006 (SYMTAB)                     0x1fc8
 0x0000000a (STRSZ)                      10876 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000003 (PLTGOT)                     0x2ea48
 0x00000002 (PLTRELSZ)                   2544 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x7a5c
 0x00000011 (REL)                        0x745c
 0x00000012 (RELSZ)                      1536 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x00000018 (BIND_NOW)
 0x6ffffffb (FLAGS_1)                    Flags: NOW
 0x6ffffffe (VERNEED)                    0x741c
 0x6fffffff (VERNEEDNUM)                 2
 0x6ffffff0 (VERSYM)                     0x6f74
 0x6ffffffa (RELCOUNT)                   153
 0x00000000 (NULL)                       0x0

$ readelf -d ./build_dir/target-arm_cortex-a8+vfpv3_musl_eabi/osmo-remsim-client-0.2.99/src/client/.libs/osmo-remsim-client-st2 

Dynamic section at offset 0x5d30 contains 36 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libosmogsm.so.13]
 0x00000001 (NEEDED)                     Shared library: [libosmoabis.so.6]
 0x00000001 (NEEDED)                     Shared library: [libosmousb.so.0]
 0x00000001 (NEEDED)                     Shared library: [libosmo-simtrace2.so.0]
 0x00000001 (NEEDED)                     Shared library: [libusb-1.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libosmo-rspro.so.1]
 0x00000001 (NEEDED)                     Shared library: [libtalloc.so.2]
 0x00000001 (NEEDED)                     Shared library: [libosmocore.so.12]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so]
 0x0000000c (INIT)                       0x11b0c
 0x0000000d (FINI)                       0x14ba8
 0x00000019 (INIT_ARRAY)                 0x25d1c
 0x0000001b (INIT_ARRAYSZ)               12 (bytes)
 0x0000001a (FINI_ARRAY)                 0x25d28
 0x0000001c (FINI_ARRAYSZ)               4 (bytes)
 0x00000004 (HASH)                       0x1014c
 0x6ffffef5 (GNU_HASH)                   0x10478
 0x00000005 (STRTAB)                     0x10ea0
 0x00000006 (SYMTAB)                     0x10820
 0x0000000a (STRSZ)                      2105 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x25e78
 0x00000002 (PLTRELSZ)                   760 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x11814
 0x00000011 (REL)                        0x117ec
 0x00000012 (RELSZ)                      40 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x00000018 (BIND_NOW)                   
 0x6ffffffb (FLAGS_1)                    Flags: NOW
 0x6ffffffe (VERNEED)                    0x117ac
 0x6fffffff (VERNEEDNUM)                 2
 0x6ffffff0 (VERSYM)                     0x116da
 0x00000000 (NULL)                       0x0

> The scope of ctor priorities is within a single DSO. Priorities are
> used by the linker to order them within the ctor array of the library. [...]

Thanks for sharing your knowledge on the topic.  So I stand corrected regarding
claiming the priority is a bug.  However, the ordering constraints of the ELF
specification don't seem to be reflected.

I can share the binaries if you'd like (armv7l) or provide you with any other
diagnostic output.

Regards,
	Harald
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

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

[Rich Felker]

On Thu, May 21, 2020 at 11:19:27PM +0200, Harald Welte wrote:
> Hi Rich,
> 
> thanks for your super-fast response.
> 
> On Thu, May 21, 2020 at 04:40:49PM -0400, Rich Felker wrote:
> > On Thu, May 21, 2020 at 10:22:53PM +0200, Harald Welte wrote:
> > > 1) if there are multiple libraries (in this example libosmocore and libtalloc,
> > >    where libosmocore depends on libtalloc), the __attribute__((constructor))
> > >    functions are not called in inverse dependency order, i.e. the talloc
> > >    ones are *not* called before those of libosmocore.
> > 
> > They should be, since commit 188759bbee057aa94db2bbb7cf7f5855f3b9ab53
> > (releases 1.1.22 and later). Are you using an older version?
> 
> 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.

> I meanwhile also found that the ELF specifications
> back to 1997 already specify that this ordering is required of a linker.

FWIW the only standards that musl purports to actually adhere to are
C, POSIX, and IEEE 754 (as referenced by C Annex F). While ELF is the
binary format used and we aim to use it in compatible ways so as not
to be gratuitously breaking, there are a lot of details that do not
match historical SysV behavior (this is also true on glibc to a lesser
extent), e.g. historical RPATH vs RUNPATH difference, LD_* vars, etc.
Dependency order for ctors was adopted as an enhancement because it
was deemed very reasonable and interacts better with other things (see
the commit message for the commit cited above) but was not part of
original requirements for musl. I only bring this up because
"historical SysV documents say you have to do things this way" is not
*automatically* a compelling argument for what musl should do, just
one ingredient for consideration.

> There clearly is no circular dependency either:
> 
> # ldd ./libosmocore.so
>         ldd (0xb6f46000)
>         libtalloc.so.2 => /usr/lib/libtalloc.so.2 (0xb6efd000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6ee2000)
>         libc.so => ldd (0xb6f46000)
> 
> # ldd ./libtalloc.so
>         ldd (0xb6f5b000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6f29000)
>         libc.so => ldd (0xb6f5b000)
> 
> and the executable linking against both of them:
> 
> # ldd /usr/sbin/osmo-remsim-client-st2
>         /lib/ld-musl-armhf.so.1 (0xb6eeb000)
>         libosmogsm.so.13 => /usr/lib/libosmogsm.so.13 (0xb6e8d000)
>         libosmoabis.so.6 => /usr/lib/libosmoabis.so.6 (0xb6e67000)
>         libosmousb.so.0 => /usr/lib/libosmousb.so.0 (0xb6e53000)
>         libosmo-simtrace2.so.0 => /usr/lib/libosmo-simtrace2.so.0 (0xb6e40000)
>         libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0xb6e23000)
>         libosmo-rspro.so.1 => /usr/lib/libosmo-rspro.so.1 (0xb6df3000)
>         libtalloc.so.2 => /usr/lib/libtalloc.so.2 (0xb6ddc000)
>         libosmocore.so.12 => /usr/lib/libosmocore.so.12 (0xb6daa000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6d8f000)
>         libc.so => /lib/ld-musl-armhf.so.1 (0xb6eeb000)
>         libosmovty.so.4 => /usr/lib/libosmovty.so.4 (0xb6d63000)
>         libosmosim.so.0 => /usr/lib/libosmosim.so.0 (0xb6d43000)
> 
> (executed using the musl ldd on the target itself)

Indeed it looks to me like this should work fine and libtalloc's ctors
should ru nbefore libosmocore's.

> Still, I can show very clearly while stepping through [remote] gdb that
> the constructor of libosmocore is called before that of talloc.

If this is >=1.1.22 then there's probably a bug in either the
topological sort or the deps-list going into it.

> I can share the binaries if you'd like (armv7l) or provide you with any other
> diagnostic output.

If it's not just that you're using an old version of musl, could you
put the binaries (full set of libs from ldd) somewhere and share a
link?

Rich

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

[Harald Welte]

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...

> FWIW the only standards that musl purports to actually adhere to are
> C, POSIX, and IEEE 754 (as referenced by C Annex F). While ELF is the
> binary format used and we aim to use it in compatible ways so as not
> to be gratuitously breaking, there are a lot of details that do not
> match historical SysV behavior (this is also true on glibc to a lesser
> extent), e.g. historical RPATH vs RUNPATH difference, LD_* vars, etc.

Does that explain why trying to LD_PRELOAD libtalloc didn't fix the
ordering either?  It was one humble attempt at manually overriding the
order (on 1.1.20).

> I only bring this up because "historical SysV documents say you have
> to do things this way" is not *automatically* a compelling argument
> for what musl should do, just one ingredient for consideration.

I would argue the compelling argument is to ensure applications (of
which probably 99% or at least 90% are written and tested with glibc)
will work ideally without porting, or without significant porting effort
and/or without subtle or not-so-subtle bugs [not claiming you did so,
just arguing hypothetically].  But then, this is just the library user
perspective of course, and everyone can run their project the way they
want.

Thanks again.

Regards,
	Harald
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

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

[Rich Felker]

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..

> > FWIW the only standards that musl purports to actually adhere to are
> > C, POSIX, and IEEE 754 (as referenced by C Annex F). While ELF is the
> > binary format used and we aim to use it in compatible ways so as not
> > to be gratuitously breaking, there are a lot of details that do not
> > match historical SysV behavior (this is also true on glibc to a lesser
> > extent), e.g. historical RPATH vs RUNPATH difference, LD_* vars, etc.
> 
> Does that explain why trying to LD_PRELOAD libtalloc didn't fix the
> ordering either?  It was one humble attempt at manually overriding the
> order (on 1.1.20).

Yes, old behavior was execution in reverse load order. This gave
something like dependency order for some very simple dependency
structures, but for LD_PRELOAD it resulted in the preloaded library's
ctors running _last_.

Rich

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

[Hauke Mehrtens]

[-- Attachment #1.1: Type: text/plain, Size: 1804 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Rich Felker]

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!

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

[Alexander 'lynxis' Couzens]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

On Fri, 22 May 2020 13:53:46 -0400
Rich Felker <dalias@libc.org> wrote:

[...]

> > > 
> > > OK, I'll inquire with OpenWRT about what's going on here..

> > 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.

> > https://patchwork.ozlabs.org/project/openwrt/patch/20200522153626.1398980-1-lynxis@fe80.eu/

Right, this is related to this bug. musl libc is one of a handful 
packages which uses

* git as source
* pinned to a git sha1
* have a PKG_VERSION which looks like a release

So increasing the PKG_VERSION wasn't doing anything to the code.

Best,
lynxis


-- 
Alexander Couzens

mail: lynxis@fe80.eu
jabber: lynxis@fe80.eu
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]