Marc Poulhiès <poulh...@adacore.com> writes:
> Hello Nicolas,
>
>>> At first view, it seems possible and desirable to merge _posix and
>>> _rtems, but working on this right now would be counter-productive.
>>>
>>> I suggest to apply patches 1-2 and fix PR114065 first.
>>>
>>> Then the cosmetic changes in patches 3-6 (and possibly a trivial
>>> backport of 8).
>>>
>>> After that, we will have all the time in the long winter afternoons to
>>> discuss file names in patch 7.
>>
>> Hello Nicolas,
>>
>> I wanted to test your latest version of the patch, but it does not apply
>> cleanly. Any chance you could send an updated version? I've tried to
>> apply over some recent revisions and also over some revisions around the
>> time you sent your mail, but none worked.
>
> I've discussed with Doug (author of the conflicting change).
>
> Overall, your change is OK, with the following exception: we can't
> change the Calendar API, so the revert is not OK. User code using the
> new "*_64" function will break. A possible solution would be to
> implement the API using your change.
>
> While looking at the changes again, I have one more comment, see below.
>
>> diff --git a/gcc/ada/s-oscons-tmplt.c b/gcc/ada/s-oscons-tmplt.c
>> index e5dad44..a64e578 100644
>> --- a/gcc/ada/s-oscons-tmplt.c
>> +++ b/gcc/ada/s-oscons-tmplt.c
>> @@ -1775,6 +1775,22 @@ CNS(MAX_tv_sec, "")
>> CND(SIZEOF_tv_nsec, "tv_nsec");
>> }
>>
>> +/*
>> +
>> + -- Functions with time_t suseconds_t timeval timespec parameters like
>> + -- clock_get{res,time} gettimeofday nanosleep
>> + -- pthread_cond_{,timed}wait select
>> + -- must be imported from the GNU C library with
>> + -- External_Name => (if Glibc_Use_Time_Bits64 then "__foo64" else
>> "foo")
>> + -- The test is safe in files that do not require GNU specifically.
>> +
>> +*/
>> +#if defined(__USE_TIME64_REDIRECTS) || (__TIMESIZE == 32 &&
>> __USE_TIME_BITS64)
>> + C("Glibc_Use_Time_Bits64", Boolean, "True", "Y2038 Glibc transition")
>
> Would it make sense to drop the "Glibc" here? Having "Glibc" means that
> we end up with glibc specifics in files that are not glibc specific (e.g.
> a-exetim__posix.adb or s-osinte__linux.ads). Are these particular macros
> glibc specific? We need these to build with other libc (e.g. musl).
As an aside: I won't promise to work on this just yet, but there's some fixes
needed
to get GNAT building on musl. If these are welcomed, I'll move it a bit
higher up on my list.
>
>> +#else
>> + C("Glibc_Use_Time_Bits64", Boolean, "False", "Y2038 Glibc transition")
>> +#endif
>> +
>> /*
>>
>> -- Sizes of various data types
>
> Thanks,
> Marc
