mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: u-uy74@aetey.se
Cc: musl@lists.openwall.com
Subject: Re: Symbol versioning approximation trips on compat symbols
Date: Thu, 24 Jan 2019 11:11:27 +0100	[thread overview]
Message-ID: <87a7jq8iwg.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <20190124092846.GA30123@example.net> (u-uy's message of "Thu, 24 Jan 2019 10:28:46 +0100")

* u-uy:

> IMVHO symbol versioning is basically aimed to hide the complexity of
> the evolution of libraries, to make certain usage cases "just work".
>
> OTOH it does not reduce the complexity under the hood but rather adds some
> extra of it. That's why I see its impact as double negative, postulating
> more complex tools and reducing the capacity of fellow integrators to
> analyze their systems.

That's certainly a valid position to take.  But the reality is that all
toolchains that target musl have symbol versioning support built into
them today, just not in the dynamic linker.  It would be far easier
unrelated upstreams if the toolchain simply did not support symbol
versioning at all (because the dynamic linker does not support it, so
it's not usable in each place where it is required anyway).  Then a
simple check for .symver support in the assembler would tell us whether
we can symbol versionining or not.

I have no idea how this current support is supposed to work,
particularly with cross-compiling.  Does everyone have to write
configure hacks for *-musl targets to disable symbol versioning support?
That goes against the mantra of testing what you use (and avoid
hard-coded knowledge about specific versions/targets).

Thanks,
Florian


  reply	other threads:[~2019-01-24 10:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-21 17:57 Florian Weimer
2019-01-24  1:43 ` Rich Felker
2019-01-24  9:28   ` u-uy74
2019-01-24 10:11     ` Florian Weimer [this message]
2019-01-24 11:09   ` Szabolcs Nagy
2019-01-24 11:18     ` Florian Weimer
2019-01-27  4:04       ` Rich Felker
2019-01-27  9:36         ` u-uy74
2019-01-28  6:34           ` Florian Weimer
2019-01-28  9:17             ` Timo Teras
2019-01-28 11:33               ` Szabolcs Nagy
2019-01-28 12:40             ` Szabolcs Nagy
2019-01-28 13:08             ` (OT?) Re: [musl] " u-uy74
2019-01-28 15:22               ` Markus Wichmann
2019-01-28 15:34                 ` Rich Felker
2019-01-28 15:29               ` Rich Felker
2019-01-29 17:13                 ` u-uy74
2019-01-30 14:57                   ` Rich Felker
2019-01-28 21:57             ` A. Wilcox
2019-01-28 22:52               ` Matias Fonzo
2019-01-28 23:12                 ` Zach van Rijn
2019-01-28 23:41                   ` A. Wilcox
2019-01-28 23:47                     ` Rich Felker
2019-01-29  3:22                       ` A. Wilcox
2019-01-29 19:40                         ` Matias Fonzo
2019-01-29 19:31                   ` Matias Fonzo

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=87a7jq8iwg.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=musl@lists.openwall.com \
    --cc=u-uy74@aetey.se \
    /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).