Re: cryptsetup 2.4.0 does not compile on musl libc anymore

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/20/21 1:48 PM, Sören Tempel wrote:
> Milan Broz <gmazyland@xxxxxxxxx> 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@xxxxxxxx
To unsubscribe send an email to dm-crypt-leave@xxxxxxxx




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux