public inbox for dm-crypt@saout.de
 help / color / mirror / Atom feed
From: Milan Broz <gmazyland@gmail.com>
To: "Sören Tempel" <soeren@soeren-tempel.net>
Cc: dm-crypt@saout.de
Subject: [dm-crypt] Re: cryptsetup 2.4.0 does not compile on musl libc anymore
Date: Fri, 20 Aug 2021 14:11:45 +0200	[thread overview]
Message-ID: <c61475f2-7bfb-12cd-e371-ae2901e1b9f0@gmail.com> (raw)
In-Reply-To: <2G61NKBKWBV6O.2B64SWFTC29R7@8pit.net>

On 8/20/21 1:48 PM, Sören Tempel wrote:
> Milan Broz <gmazyland@gmail.com> wrote:
>> Please create an issue in upstream project
>> https://gitlab.com/cryptsetup/cryptsetup/-/issues/new
> 
> Sorry, I don't have a gitlab.com account.

ok, just it is always better to have discussion there,
also you get mail ince it is fixed in git.
(And this list apparently keep some replies in moderation queue...)

>> The dlvsym() is crucial to the LUKS2 external token extension, so perhaps
>> the only solution would be to compile without external tokens for these
>> constrained libc systems.
> 
> Only dlvsym is a GNU extension, dlsym itself is mandated by POSIX.1-2008
> and as such also available on musl libc. I haven't looked at the
> cryptsetup implementation in detail, but maybe dlsym can be used as a
> fallback if __GLIBC__ is not defined?

We discussed that and seems there are different opinions if it should
be supported. We have very strict requirements what plugin exports
and there is possibility that API will change in future.
(A plugin providing both versions of functions then risks musl
loads the wrong version.)
> Compiling with --disable-external-tokens is also fine for now, the main
> issue is the all-symbols-test since it is compiled unconditionally.

Yes, this is easy to fix (by skipping the test if that API is not available).

>> And please, report this sooner - we released release-candidates
>> exactly to find such problems.  But people still do the same - waiting
>> for final release, then complain that something is broken. We cannot
>> fix things that we do not know about.
> 
> I am sorry, I don't always have the time to test release candidates.
> Also: I am not complaining just wanted to inform you about this.

Sorry, I did not want to be rude. Just it happens every time, that the day
after release we get a report that is trivial to fix before final version
- just if we know about it :-)

Thanks,
Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

  reply	other threads:[~2021-08-20 12:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18 17:56 [dm-crypt] cryptsetup 2.4.0 does not compile on musl libc anymore Sören Tempel
2021-08-20  8:20 ` [dm-crypt] " Milan Broz
2021-08-20 11:48   ` Sören Tempel
2021-08-20 12:11     ` Milan Broz [this message]
2021-08-22 12:58       ` Milan Broz

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=c61475f2-7bfb-12cd-e371-ae2901e1b9f0@gmail.com \
    --to=gmazyland@gmail.com \
    --cc=dm-crypt@saout.de \
    --cc=soeren@soeren-tempel.net \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox