Peter Selinger

Thanks. The git repo you modified seems to be a snapshot of an (even) older version of ccrypt. I have made the update ("(dé)chiffrage" -> "(dé)chiffrement.") in my upstream version. Ccrypt is infrequently released since it basically doesn't change, so I'm not sure when release 1.12 will come out.

Hi, thanks for this. However, that is not what the fix is. What needs to be removed is the dependency on libcrypt3 (the "unix crypt" library), not the --unixcrypt functionality. Ccrypt already emulates libcrypt3, so all that needs to be done is basically use --disable-libcrypt every time, instead of trying to use the system-wide libcrypt3. I've already fixed this upstream, but I haven't made a release yet.

Thanks for reporting; this is a duplicate of https://sourceforge.net/p/ccrypt/bugs/30/.

This is a duplicate of https://sourceforge.net/p/ccrypt/bugs/24/ and https://sourceforge.net/p/ccrypt/bugs/30/.

Great, thanks for the clarification. According to the documentation, (make-vector 31 0) should be both backward and forward compatible. That change was already made with https://sourceforge.net/p/ccrypt/bugs/30/, though I haven't yet made a release since then.

Will this break support for Emacs versions prior to 30.1?

Thanks for the suggestion. I ended up removing the Intel-specific tweaks altogether, since the code where it was used wasn't a performance bottleneck.

I386 feature should not be enabled on non-x86 architecutre