Is it time for a libc_fixes library yet?

[Ken Cunningham]

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