<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">No reason at all, other than how I discovered them along the way! I have used AOS exclusively for months; I think these were the two original ones I replaced, last year. <div><br></div><div>I will see how these can replace the existing ones.<div><br></div><div>In the end, I sincerely hope this helps make supporting these older systems so easy that it is a non-issue for port developers. No tickets means happy port devs and happy users!</div><div><br></div><div>Ken</div><div><br><div><div><div>On 2017-07-03, at 1:56 PM, Stephen J. Butler wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">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.<div><br></div><div><a href="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/getdelim.c.auto.html</a><br></div><div><br></div><div><a href="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/stdio/FreeBSD/getline.c.auto.html</a><br></div><div><br></div><div><a href="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/strndup.c.auto.html</a><br></div><div><br></div><div><a href="https://opensource.apple.com/source/Libc/Libc-1158.50.2/string/FreeBSD/strnlen.c.auto.html">https://opensource.apple.com/source/Libc/Libc-1158.50.2/string/FreeBSD/strnlen.c.auto.html</a><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 3, 2017 at 3:26 PM, Ken Cunningham <span dir="ltr"><<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank">ken.cunningham.webuse@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I see a general frustration with the current situation has led things to move along rather quicker than I had originally thought they might.<br>
<br>
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...<br>
<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
K<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 2017-07-03, at 1:09 PM, Rainer Müller wrote:<br>
<br>
> On 2017-07-03 19:07, Ken Cunningham wrote:<br>
>> So the last 10 or so tickets in trac seem like they are all for<br>
>> basically the same issue - a few missing symbols from libc prior to 10.7.<br>
><br>
> Well, I would take this as a reason to just drop support for such an old<br>
> OS release... I know, I cannot convince you to do that yet. ;-)<br>
><br>
>> It is easy enough, but time consuming, to patch each individual source<br>
>> file that is missing the definition (there might be several, also, so<br>
>> you might have to do it multiple times in different files).<br>
>><br>
>> With this library of these missing functions<br>
>> <<a href="https://github.com/kencu/snowleopardfixes" rel="noreferrer" target="_blank">https://github.com/kencu/<wbr>snowleopardfixes</a>>, all of them from the Apple<br>
>> open source website IIRC, all you need to do is the following in the<br>
>> Portfile:<br>
>><br>
>> if{${os.platform}eq "darwin"&& ${os.major} < 11} |{ depends_lib-append<br>
>> port:snowleopardfixes configure.ldflags-append -lsnowleopardfixes } |<br>
><br>
> Taking a quick look at this library, all implementations seem to be<br>
> covered by GPL-2+.<br>
><br>
> That makes this library not suitable for many ports, as the result after<br>
> linking would no longer be distributable. It would be better to use<br>
> implementations under a non-copyleft license such BSD, MIT, ISC, etc.<br>
><br>
>> It could be better named, perhaps libcfixes, as it applies to 10.4 to<br>
>> 10.6, not just SnowLeopard.<br>
><br>
> I would not declare theses as "fixes", but rather as "supplements"<br>
> providing additional functions not available in libc.<br>
><br>
>> Addendum 1<br>
>><br>
>> I have a header in there as well to provide the function definitions,<br>
>> but that header can cause trouble by bringing in other #defines, and it<br>
>> seems that no port actually needs the header. Perhaps the header idea<br>
>> can be improved by someone with more knowledge of #include_next, etc, or<br>
>> more specific defines.<br>
><br>
> I guess you would see compiler warnings about implicit declarations?<br>
><br>
> As an example, if the compiler assumes a declaration like<br>
> int strnlen(int, int)<br>
> instead of<br>
> size_t strnlen(const char *s, size_t maxlen)<br>
> that could still work as long as sizeof(int) == sizeof(char*), because<br>
> the parameters are passed with the same calling convention. However,<br>
> this might fail in other cases at runtime (structs, floats, ...).<br>
> Although it might still work correctly for builtins, for which the<br>
> compiler actually knows the declaration.<br>
><br>
> To avoid exposing too many functions, the declarations could be<br>
> controlled with preprocessor conditions.<br>
><br>
> #if !defined(SNOWLEOPARDFIXES_<wbr>MANUAL_MODE) ||<br>
> defined(SNOWLEOPARDFIXES_<wbr>STRNLEN)<br>
> size_t strnlen(const char *s, size_t maxlen)<br>
> #endif<br>
><br>
>> Addendum 2<br>
>><br>
>> As we have said before (last year) this library could be automatically<br>
>> linked in by base. That would cause trouble with the ports that have<br>
>> already patched in a def, tho.<br>
><br>
> If this library itself were in base, adding new functions would require<br>
> a new base release. So you would still need local patches, which later<br>
> break with the new release...<br>
><br>
> base could automatically add it as a dependency, with the port being in<br>
> our ports tree.<br>
><br>
> Rainer<br>
<br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></body></html>