Is it time for a libc_fixes library yet?

[Ryan Schmidt]

On Jul 4, 2017, at 09:12, Ken Cunningham 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?
> 
> 
> Very good point. So far, all the ports I've tested either assume the 2008 standard, or don't. So it has never happened yet. But in such as case, at least for now, we'd have to go back to the manual patching method we've used over time.
> 
> We could put #defines around each function, and specifically request them with env variables or something -- but that gets very confusing I would argue, and gets away from the thrust of this.
> 
> I would say this solves the issue for >90% of the situations so far. And if so, that's a lot less work. So better, I hope, but not perfect.

Good to know. I'm just thinking about developers who don't test on macOS at all, and I have no idea what set of functions other operating systems contain. I also wouldn't be surprised to learn that developers don't know what functions are in what standard (I certainly don't) and don't know which ones need compatibility functions and which don't, and provide only a partial set.


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

If you're suggesting modifying the capabilities of the clang compiler that the MacPorts ports install, I would advise against that. Users who, for example, install clang on Snow Leopard might do so because they want to use it to compile their own software. They will want the standard clang compiler, not one that has nonstandard modifications.


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

I understand some developers might not respond to these requests, or they might respond that they will not fix the problem. But I want our attempts to contact the developers to be documented. Fixing it upstream is better, so I want to make sure that in each case we give upstream the opportunity to do so. If I see a port that just includes the portgroup, that doesn't tell me anything about whether we've attempted to have that conversation with the developer yet.