Is it time for a libc_fixes library yet?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Is it time for a libc_fixes library yet?

Kenneth F. Cunningham
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).

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. 

It works for wine, and all the other ports that have had this issue. It takes 10 seconds to do, and no patching.

Is it time for this? Or shall we continue as we are?


Best,

Ken




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.

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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it time for a libc_fixes library yet?

Marius Schamschula-3
Ken,

Yes please! I’ve lost count of how many ports I have had patch this fix into.

On Jul 3, 2017, at 12:07 PM, Ken Cunningham <[hidden email]> 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).

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. 

It works for wine, and all the other ports that have had this issue. It takes 10 seconds to do, and no patching.

Is it time for this? Or shall we continue as we are?


Best,

Ken




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.

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.


Marius
--
Marius Schamschula




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it time for a libc_fixes library yet?

Rainer Müller-4
In reply to this post by Kenneth F. Cunningham
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it time for a libc_fixes library yet?

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it time for a libc_fixes library yet?

Mojca Miklavec-2
In reply to this post by Rainer Müller-4
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.

We should really really really really deploy the libc++ build slaves.

Mojca
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it time for a libc_fixes library yet?

Stephen J. Butler
In reply to this post by Kenneth F. Cunningham

On Mon, Jul 3, 2017 at 3:26 PM, Ken Cunningham <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it time for a libc_fixes library yet?

Kenneth F. Cunningham
No reason at all, other than how I discovered them along the way! I have used AOS exclusively for months; I think these were the two original ones I replaced, last year.  

I will see how these can replace the existing ones.

In the end, I sincerely hope this helps make supporting these older systems so easy that it is a non-issue for port developers. No tickets means happy port devs and happy users!

Ken

On 2017-07-03, at 1:56 PM, Stephen J. Butler wrote:


On Mon, Jul 3, 2017 at 3:26 PM, Ken Cunningham <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it time for a libc_fixes library yet?

Stephen J. Butler
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.

On Mon, Jul 3, 2017 at 4:01 PM, Ken Cunningham <[hidden email]> wrote:
No reason at all, other than how I discovered them along the way! I have used AOS exclusively for months; I think these were the two original ones I replaced, last year.  

I will see how these can replace the existing ones.

In the end, I sincerely hope this helps make supporting these older systems so easy that it is a non-issue for port developers. No tickets means happy port devs and happy users!

Ken

On 2017-07-03, at 1:56 PM, Stephen J. Butler wrote:


On Mon, Jul 3, 2017 at 3:26 PM, Ken Cunningham <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it time for a libc_fixes library yet?

Ryan Schmidt-24
In reply to this post by Kenneth F. Cunningham

On Jul 3, 2017, at 12:07, Ken Cunningham wrote:

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.

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?


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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it time for a libc_fixes library yet?

Kenneth F. Cunningham
>
> 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.


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

Thanks!

Ken

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it time for a libc_fixes library yet?

Kenneth F. Cunningham
>
>
> 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.
>

Well, another fairly easy option would be to bring down the newer libc from 10.7 and port it back into 10.4 to 10.6, with some mods to the headers to support the new functions.  That would also be quite doable.  But  who knows what that would break ?

I know that is a total non-starter, so I didn't bother.

K
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it time for a libc_fixes library yet?

Ryan Schmidt-24
In reply to this post by Kenneth F. Cunningham

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.


Loading...