Is it time for a libc_fixes library yet?

[Jan Stary]

On Jul 03 10:07:18, ken.cunningham.webuse at gmail.com 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.
> 
> 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).

The real bug is in the upstream which does not care about portability.
Most often, it is one of the auto* tools doing

	GNU version string => good
	anything else      => bad

without ever checking for the function/feature itself.
http://marc.info/?l=openbsd-ports&m=126805847322995&w=2


> 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
> }
> It could be better named, perhaps libcfixes, as it applies to 10.4 to 10.6, not just SnowLeopard. 

Call it kenutils or libcompat (or something); it's not specific to any version of MacOSX
(or any other system, for that matter) and it does not "fix libc".

More importantly, it masks the real problem: upstream will never get fixed.
Tell upstream to provide a compat_*.c for systems that don't have the function.
It's not hard to do - here is how the portable mandoc does it:
http://mdocml.bsd.lv/cgi-bin/cvsweb/

Chances are upstream will not care that their software does not compile
on older MacOSes. But we should still tell them, over and over.
I understand your library is meant precisely to avoid that ...


> 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.

Please don't.


On Jul 03 22:09:27, raimue at macports.org wrote:
> 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.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/



On Jul 03 16:05:04, stephen.butler at gmail.com wrote:
> I just noticed that the getdelim code manipulates the FILE* directly, so
> that's not allowed in your lib. But it's essentially just filling a buffer
> with data, processing it, and checking feof()/ferror() along the way.
> Nothing complicated you can't reproduce with std api's.

http://mdocml.bsd.lv/cgi-bin/cvsweb/compat_getline.c?rev=1.1&content-type=text/x-cvsweb-markup


On Jul 03 22:51:37, mojca at macports.org wrote:
> On 3 July 2017 at 22:09, 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. ;-)
> 
> MacPorts is basically the only thing that keeps those OSes useful :)
> I'm grateful for enthusiasts like Ken who make effort to keep the MP
> working there in the best possible way.
> And mostly to Jeremy who made sure that clang works.

Absolutely. I only have a 10.5.8 and a 10.6.8
and MacPorts makes these a lot more useful.

While I appreciate all the effort that goes into keeping software usable on these systems,
I believe this kind of fix should really be pushed upstream.

On Jul 04 03:38:31, ryandesign at macports.org wrote:
> Your library offers multiple functions... getline, strndup, etc.
> What happens if a software package provides, for example, a compatibility implementation of getline but not strndup? Can your library be used in this case or will that also "cause trouble", as you put it above?

Ken's library does not check whether the given function
is provided but the underlying system at all (right?).
The cleanest way I have seen is how mandoc does it:

http://mdocml.bsd.lv/cgi-bin/cvsweb/configure
http://mdocml.bsd.lv/cgi-bin/cvsweb/configure.local.example

Yes, that's a hand-written ./configure script; orders of magnitude
smaller than the auto-* produced atrocities.

> I see the port and a portgroup have been added to MacPorts. I would like to request that each port that adopts this port/portgroup also add a comment explaining upstream's stance on the issue. For example, a link to the upstream bug report.

+1

> Perfect would be if I just wrote it into the clang code directly.
> I am almost to the point where I could do that, actually. I know where it would go, I think.

I don't get it. Do you mean to mess with the compiler so that
it implements itself the C functions that the system does not provide?

> You are 100% correct that upstream should do this, and this is far better. I should say over the past year I can't think of a single instance where I saw that upstream actually did add one of these old functions, though. Maybe you know of some cases.

If the upstream is Linux, they mostly don't care as long as glibc has the function.
But they should be told that the software is unportable, even as we try to port it.

> autotools is an ugly thing to learn beyond the defaults.
> And I still don't see how to do this kind of thing by default with cmake.

autotools and cmake should have nothing to do with this.

	Jan