crypt_data namespace collision

[jhgit]

trafficstars

For some operating systems, such as FreeBSD, struct crypt_data is defined in the unistd.h system header.

In the error output below, libxcrypt's crypt.h is in /usr/local/include...

In file included from ../src/libaccountsservice/act-user.c:30: /usr/local/include/crypt.h:73:8: error: redefinition of 'crypt_data' struct crypt_data ^ /usr/include/unistd.h:489:8: note: previous definition is here struct crypt_data { ^

I don't have a good solution yet. One possibility might be to rename crypt_data in libxcrypt to something else (xcrypt_data, for example).

[Artoria2e5]

Hmmm... Looks like freebsd unistd also has crypt and crypt_r. That would also cause some redeclaration issues down the line once the struct is renamed, I guess.

xcrypt_* used to be a thing, but it's deprecated.

[zackw]

Before we can practically do anything about this, we need to decide: should libxcrypt on FreeBSD be a binary compatible drop-in replacement for FreeBSD's libcrypt.so.5 ? If so, we will need to keep the names the same, and we will need to figure out a way to reconcile libxcrypt's definition of crypt_data

https://github.com/besser82/libxcrypt/blob/72f75aa370ae96ccd2cc44ea3cf4182d8679ffbe/lib/crypt.h.in#L70-L109)

with FreeBSD's different, much smaller definition

struct crypt_data {
        int     initialized;    /* For compatibility with glibc. */
        char    __buf[256];     /* Buffer returned by crypt_r(). */
};

If binary backward compatibility is not desirable on FreeBSD, then we should probably rename all the functions and not provide crypt or crypt_r at all.

I am only an occasional user of FreeBSD and am in no way qualified to decide whether libxcrypt should be binary compatible with libcrypt.so.5. We need to hear from FreeBSD core developers about what they think would be appropriate here.

I would personally be happy to cooperate with an effort to make libxcrypt more usable on FreeBSD, including both binary compatibility and replacing all the rest of the surviving (L)GPL code so that it could be adopted officially, but I do not have time to do the work myself, and I do not know whether the other core libxcrypt developers (@besser82, @solardiz, @vt-alt) would be on board with this.

[solardiz]

It could help us to know the use cases people are now trying to use libxcrypt on FreeBSD for. What was yours, @jhgit?

[Artoria2e5]

I am not the issue author, but today (or rather, past me from a 3 years ago) I did come across one case where there is a point for libxcrypt to act independently of libc headers. In https://github.com/nuvious/pam-duress/issues/14 I mentioned that a little bit of libxcrypt can be used instead of the libc implementation to offer stronger algorithms on unsupported platforms, but that probably won't work given the current collision.