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

[Rich Felker <dalias@libc.org>]

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