Is there a reason to not use the Apple/FreeBSD Libc versions? I see you used the same one they did for memmem and wcsdup.
https://opensource.apple.com/source/Libc/Libc-1158.50.2/stdio/FreeBSD/getdelim.c.auto.html https://opensource.apple.com/source/Libc/Libc-1158.50.2/stdio/FreeBSD/getline.c.auto.html https://opensource.apple.com/source/Libc/Libc-1158.50.2/string/FreeBSD/strndup.c.auto.html https://opensource.apple.com/source/Libc/Libc-1158.50.2/string/FreeBSD/strnlen.c.auto.html On Mon, Jul 3, 2017 at 3:26 PM, Ken Cunningham < ken.cunningham.web...@gmail.com> wrote: > I see a general frustration with the current situation has led things to > move along rather quicker than I had originally thought they might. > > I will never know as much about licensing as you do. I hope this can be > worked out to advantage. I notice most of this code is already being pasted > in as patches, and it's in the files directory of many ports... > > Right now this library is a dylib, as you previously recommended. Hope > that helps. Will seek out any more liberal implementations. Most of these > came for Apple open source, I think, over the past year. > > > K > > > On 2017-07-03, at 1:09 PM, Rainer Müller wrote: > > > On 2017-07-03 19:07, Ken Cunningham wrote: > >> So the last 10 or so tickets in trac seem like they are all for > >> basically the same issue - a few missing symbols from libc prior to > 10.7. > > > > Well, I would take this as a reason to just drop support for such an old > > OS release... I know, I cannot convince you to do that yet. ;-) > > > >> It is easy enough, but time consuming, to patch each individual source > >> file that is missing the definition (there might be several, also, so > >> you might have to do it multiple times in different files). > >> > >> With this library of these missing functions > >> <https://github.com/kencu/snowleopardfixes>, all of them from the Apple > >> open source website IIRC, all you need to do is the following in the > >> Portfile: > >> > >> if{${os.platform}eq "darwin"&& ${os.major} < 11} |{ depends_lib-append > >> port:snowleopardfixes configure.ldflags-append -lsnowleopardfixes } | > > > > Taking a quick look at this library, all implementations seem to be > > covered by GPL-2+. > > > > That makes this library not suitable for many ports, as the result after > > linking would no longer be distributable. It would be better to use > > implementations under a non-copyleft license such BSD, MIT, ISC, etc. > > > >> It could be better named, perhaps libcfixes, as it applies to 10.4 to > >> 10.6, not just SnowLeopard. > > > > I would not declare theses as "fixes", but rather as "supplements" > > providing additional functions not available in libc. > > > >> Addendum 1 > >> > >> I have a header in there as well to provide the function definitions, > >> but that header can cause trouble by bringing in other #defines, and it > >> seems that no port actually needs the header. Perhaps the header idea > >> can be improved by someone with more knowledge of #include_next, etc, or > >> more specific defines. > > > > I guess you would see compiler warnings about implicit declarations? > > > > As an example, if the compiler assumes a declaration like > > int strnlen(int, int) > > instead of > > size_t strnlen(const char *s, size_t maxlen) > > that could still work as long as sizeof(int) == sizeof(char*), because > > the parameters are passed with the same calling convention. However, > > this might fail in other cases at runtime (structs, floats, ...). > > Although it might still work correctly for builtins, for which the > > compiler actually knows the declaration. > > > > To avoid exposing too many functions, the declarations could be > > controlled with preprocessor conditions. > > > > #if !defined(SNOWLEOPARDFIXES_MANUAL_MODE) || > > defined(SNOWLEOPARDFIXES_STRNLEN) > > size_t strnlen(const char *s, size_t maxlen) > > #endif > > > >> Addendum 2 > >> > >> As we have said before (last year) this library could be automatically > >> linked in by base. That would cause trouble with the ports that have > >> already patched in a def, tho. > > > > If this library itself were in base, adding new functions would require > > a new base release. So you would still need local patches, which later > > break with the new release... > > > > base could automatically add it as a dependency, with the port being in > > our ports tree. > > > > Rainer > >