* [musl] MUSL ignores__attribute__((constructor(priority))) ? @ 2020-05-21 20:22 Harald Welte 2020-05-21 20:40 ` Rich Felker 0 siblings, 1 reply; 9+ messages in thread From: Harald Welte @ 2020-05-21 20:22 UTC (permalink / raw) To: musl 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] MUSL ignores__attribute__((constructor(priority))) ? 2020-05-21 20:22 [musl] MUSL ignores__attribute__((constructor(priority))) ? Harald Welte @ 2020-05-21 20:40 ` Rich Felker 2020-05-21 21:19 ` Harald Welte 0 siblings, 1 reply; 9+ messages in thread From: Rich Felker @ 2020-05-21 20:40 UTC (permalink / raw) To: Harald Welte; +Cc: musl 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] MUSL ignores__attribute__((constructor(priority))) ? 2020-05-21 20:40 ` Rich Felker @ 2020-05-21 21:19 ` Harald Welte 2020-05-21 21:49 ` Rich Felker 0 siblings, 1 reply; 9+ messages in thread From: Harald Welte @ 2020-05-21 21:19 UTC (permalink / raw) To: Rich Felker; +Cc: musl 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] MUSL ignores__attribute__((constructor(priority))) ? 2020-05-21 21:19 ` Harald Welte @ 2020-05-21 21:49 ` Rich Felker 2020-05-22 16:50 ` Harald Welte 0 siblings, 1 reply; 9+ messages in thread From: Rich Felker @ 2020-05-21 21:49 UTC (permalink / raw) To: Harald Welte; +Cc: musl 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] MUSL ignores__attribute__((constructor(priority))) ? 2020-05-21 21:49 ` Rich Felker @ 2020-05-22 16:50 ` Harald Welte 2020-05-22 17:33 ` Rich Felker 0 siblings, 1 reply; 9+ messages in thread From: Harald Welte @ 2020-05-22 16:50 UTC (permalink / raw) To: Rich Felker; +Cc: musl 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] MUSL ignores__attribute__((constructor(priority))) ? 2020-05-22 16:50 ` Harald Welte @ 2020-05-22 17:33 ` Rich Felker 2020-05-22 17:45 ` Hauke Mehrtens 0 siblings, 1 reply; 9+ messages in thread From: Rich Felker @ 2020-05-22 17:33 UTC (permalink / raw) To: Harald Welte; +Cc: musl 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] MUSL ignores__attribute__((constructor(priority))) ? 2020-05-22 17:33 ` Rich Felker @ 2020-05-22 17:45 ` Hauke Mehrtens 2020-05-22 17:53 ` Rich Felker 0 siblings, 1 reply; 9+ messages in thread From: Hauke Mehrtens @ 2020-05-22 17:45 UTC (permalink / raw) To: musl, Rich Felker, Harald Welte; +Cc: Alexander Couzens [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] MUSL ignores__attribute__((constructor(priority))) ? 2020-05-22 17:45 ` Hauke Mehrtens @ 2020-05-22 17:53 ` Rich Felker 2020-05-22 23:37 ` Alexander 'lynxis' Couzens 0 siblings, 1 reply; 9+ messages in thread From: Rich Felker @ 2020-05-22 17:53 UTC (permalink / raw) To: Hauke Mehrtens; +Cc: musl, Harald Welte, Alexander Couzens 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! ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [musl] MUSL ignores__attribute__((constructor(priority))) ? 2020-05-22 17:53 ` Rich Felker @ 2020-05-22 23:37 ` Alexander 'lynxis' Couzens 0 siblings, 0 replies; 9+ messages in thread From: Alexander 'lynxis' Couzens @ 2020-05-22 23:37 UTC (permalink / raw) To: Rich Felker; +Cc: Hauke Mehrtens, musl, Harald Welte [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-05-22 23:37 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-21 20:22 [musl] MUSL ignores__attribute__((constructor(priority))) ? Harald Welte 2020-05-21 20:40 ` Rich Felker 2020-05-21 21:19 ` Harald Welte 2020-05-21 21:49 ` Rich Felker 2020-05-22 16:50 ` Harald Welte 2020-05-22 17:33 ` Rich Felker 2020-05-22 17:45 ` Hauke Mehrtens 2020-05-22 17:53 ` Rich Felker 2020-05-22 23:37 ` Alexander 'lynxis' Couzens
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).