From: Harald Welte <laforge@gnumonks.org>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re: [musl] MUSL ignores__attribute__((constructor(priority))) ?
Date: Fri, 22 May 2020 18:50:06 +0200 [thread overview]
Message-ID: <20200522165006.GR2993937@nataraja> (raw)
In-Reply-To: <20200521214948.GL1079@brightrain.aerifal.cx>
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)
next prev parent reply other threads:[~2020-05-22 16:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-21 20:22 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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200522165006.GR2993937@nataraja \
--to=laforge@gnumonks.org \
--cc=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).