On 22/07/03 07:50PM, David H. Gutteridge wrote: > > Something to think about with both libbsd and libmd is if they should > provide proper built-in detection. libbsd has an attempt at it, but > seems wrong to me, as it doesn't work on BSDs. (I guess the assumption > is that no one would choose to build it in that context, and depending > packages would conditionally handle this. Yes, I haven't touched the original builtin.mk of libbsd-0.10.0. Indeed, it only checks if libbsd is already available on the host system. There's no wrapper to test supported functions/calls and verify their compatibility} with those provided by libbsd. My take? Somebody more experienced than me could look at the libbsd code and port whatever function is lacking to libncompat. Then all packages relying on libbsd could have a conditional to include the required headers whenever `HAVE_NBCOMPAT_H' is defined. NetBSD could for example benefit from having compatibility for explicit_bzero(), readpassprhase(), strtofflags(), pledge(), freezero(), and recallocarray(). iAtthe same time, libbsd includes support for NetBSD-specific functions like strtoi() and strtou(), and uses NetBSD's vins/unvis. > though they don't seem to entirely consistently or correctly, e.g., > audio/rtunes or graphics/scrot.) The packages currently depending on libbsd usually only include libbsd's buildlnk3.mk if the target platform is either Linux or different from *BSD. No clear standardised behavior. Undefined *BSD is a too generic assumption and not very robust imho. It works with older packages, but not with new software designed on and for any of the BSDs, which typically relies on system-specific features, making it non portable across BSDs. Packages currently requiring libbsd on Linux are usually tools ported from OpenBSD, and sometimes from other BSDs. It's not like they will simply compile on NetBSD without patches. A major shortcoming of linking to libbsd anywhere outside of *BSD (which is for example what audio/rtunes does), is that the target platform may not need libbsd as much as Linux does or not need it at all. This is the case of illumos for example, and to a good extent, Solaris 11. libbsd won't compile here. macOS is an exception (libbsd can be found in MacPorts), but this is probably the consequence of a stronger focus and attention to the platform. I think this thread as a whole raises the question about the potential need of a reworked userspace shim for BSD functions capable of building on NetBSD first, and other platforms later on. > Trying to build the current libbsd 0.10 on NetBSD 9.99.97/amd64 fails > with: > > In file included from arc4random.c:33: > ../include/bsd/unistd.h:62:6: error: conflicting types for 'closefrom' > 62 | void closefrom(); > | ^~~~~~~~~ > In file included from ../include/bsd/unistd.h:31, > from arc4random.c:33: > /usr/include/unistd.h:329:6: note: previous declaration of 'closefrom' > was here > 329 | int closefrom(int); > | ^~~~~~~~~ > *** [arc4random.lo] Error code 1 > > make[2]: stopped in > /home/disciple/pkgsrc/devel/libbsd/work/libbsd-0.10.0/src > 1 error > > I see you found the same, and it sounds like it may be complicated to > resolve. Yes, and pretty much any other function will have some conflicting declaration. I had come to the point of successfully building arc4random and getopt, but then gave up in front of the fact the rest also required a non-negligible amount of work (at least for me). An alternative approach would be to try to compile only what's needed on NetBSD (as I did for wip/signify, but it was a much simpler package). > Built-in handling for libmd would be a bit more complicated, I think, > given there are more OSes involved (and SunOS variants, perhaps). It would; however libmd is a very small package and compiles fast, even on SunOS (tested). So the effort required for a homebrew library could be spared? > I'd prefer it to have a working built-in guard, as above, but that may > be non-trivial. Others may have a different opinion than me. I'm fine with them staying in wip, as long as they work on Linux. Platform-specific stuff doesn't really fit pkgsrc. > Sure, though I don't see many actual dependencies in pkgsrc itself, and > presumably 0.10 satisfies them all (no idea), so I don't see a > particular urgency to this, personally. It's a nice to have. (Maybe I'm > missing something?) Please don't get me wrong, certainly the efforts > you're making are appreciated! Oh, sure, I simply notified it,in light of the relevant TODO note in pkgsrc and the fact you asked me about getting te latest version in repo. I was playing at packaging a couple of things which required libbsd>=0.11.0, and that's why I started the thread in the first place. The only possibly relevant package to require libbsd>=0.11.0 and libmd is the portable version of the got VCS from OpenBSD (wip/got-portable), which I packaged a while ago and works fine on Linux as long as these dependencies are satisfied. It should be noted, however, that the package builds just fine on NetBSD without neither libbsd nor libmd and so so does on Darwin. Then again, I'm perfectly fine with libbsd 0.11.6 staying in wip, given the very small amount of packages requiring it. My objective was to get a working up to date version in pkgsrc, and apparently this is the case now (albeit it needs testing) Side Note: as far as I cant tell net/ucspi-tools is the only optionally-libbsd-dependent package which builds on Linux. I remember having some issue with graphics/scrot, which I worked out with a local patch. > Yes, I noticed the entry was wrong for the package, too. It looks like > it should actually list four or five different licenses, similar to > what you've done for libmd. To be 100% honest, I find this license (and other similar, like wtf), just a way to complicate the life of whomever wants to use author's code and implement it in a differently licensed project. The developer may just stick with 2-CLAUSE-BSD if complete freedom and minimalism are the goal, since the license is well-known, broadly adopted and has no pending compliance evaluation on it. I haven't investigated further in this topic, but I think that, since all Linux distros provide libbsd and libmd binaries, it should really be a concern. Kindest Regards, PVO -- ----------------------------+---------------------------- vms[-at]retrobsd.ddns.net | https://retrobsd.ddns.net
Attachment:
signature.asc
Description: PGP signature