RTEMS | Re-import libcrypt as a proper 3rd-party library (#5332)

Fri Sep 5 03:19:16 UTC 2025

Kinsey Moore created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5332

## Summary
`libcrypt` as it exists in cpukit is not maintainable in the sense that there is no real way to update it from the upstream source in FreeBSD due to the changes that have been made and the unknown state in which it was imported while already modified.

As it stands, there are many modifications that are not called out as such with conditionals on `__rtems__` and while some of those exist in the git history, others were applied before import. `crypt.c` has been rewritten from scratch as compared to the modern source in FreeBSD and `crypt.h` has been heavily modified.

The version of `libcrypt` in RTEMS is most similar to FreeBSD hash e4978d34f212568. The changes introduced need to be understood and then the up to date source imported into contrib/cpukit and made to work with RTEMS with the current understanding of 3rd party imports and without altering how RTEMS uses this library. Existing APIs must be preserved as the crypt.h header has been installed as part of every BSP for use by the application developer.
### Pre-set options

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5332
You're receiving this email because of your account on gitlab.rtems.org.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20250905/b21133f6/attachment.htm>