Is it time for a libc_fixes library yet?

[Rainer Müller]

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