Is it time for a libc_fixes library yet?

[Stephen J. Butler]

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.webuse at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20170703/97422914/attachment-0001.html>