On 2/18/25 15:52, Stuart Henderson wrote: > On 2025/02/18 14:55, Christian Schulte wrote: > > However static libraries are not usually all that useful in > ports/packages. When they're used it is a pain because we need to chase > through the tree to find other ports to bump after an update. In the > past we used these a bit for software frequently installed in a chroot > jail, but usually it's simpler to copy the libraries into the jail > instead. Otherwise the main use is for things linking against OpenSSL > libraries to slightly reduce the problems when there are conflicts > with LibreSSL (but this is only of limited help, some things still > don't work). For the most part they just waste link time, disk space, > and bandwidth. > >> It should be straight forward to just do this manually >> without cmake, configure, whatever. > > Yes, sure. And it's easy but different on most OS where you might want > to do this. But fortunately developers of most ported software don't do > this and use a few fairly common methods so that we don't need to keep > patching things for the way OpenBSD does it across the tree, and can > largely confine to modules dealing with certain build systems. >
Ok. So here is an initial attempt to create that port. Just a header and a library. I am not sure about the values I need to provide in that Makefile so I left them commented out. It builds and installs. The application I am needing it for also builds and works with it on OpenBSD. This is the version currently shipped with Debian stable. The author already provided a version 2 and a version 3. Both incompatible. Maybe if other OSes start providing those, I may add ports for libjwt2 and libjwt3 as well, when they stabilized. Not sure something this trivial really is worth adding to the ports tree. But a great starting point for someone never having created a port before and never having used cmake for anything. -- Christian
libjwt.tar.gz
Description: application/gzip