"GNU Ports for eCS Mailing List" <email@example.com>
In <firstname.lastname@example.org>, on 12/31/18
at 01:54 AM, "Lewis G Rosenthal" <email@example.com> said:
>This all makes sense. I was wondering how or where I might find a native
>OS/2 API poking up its head in a bunch of *ix code.
This did happen more in the past when the upstream maintainers would
accept OS/2 patches.
>This also makes sense, as it's not "all" *ix code.
This goes back to the days when the upstream APR maintainers accepted OS/2
patches. This all happened before kLIBC existed. Reworking the APR now
to use kLIBC rather than native OS/2 APIs would require capable developers
with the desire and time to do the work.
>Ah. So, as soon as I see a reference to os2.h, it is logical to assume
>(as far as that gets us) that at least one OS/2 API may be in use
>(unless it's just some old cruft which was never pulled out).
The later is unlikely. If this did occur, the app would like have a lot
of OS/2 code with significant bit-rot. The chances of the app building
for OS/2 without major rework is low.
>> The important question is when an app being ported to kLIBC does use an
>> OS/2 API that is not high memory safe what is the best method to
>> remediate the issue.