R devel - Apr 2020 - R 4.0.0 build error with sysdata.rda on ppc64el architecture

On 29 April 2020 at 11:22, peter dalgaard wrote:
| Hum, at least it is not Apple, so maybe you can attach a debugger to the
running process? (gdb -p process_id or something like that --- haven't
actually done it for a decade). Then at least we can get a stack trace and a
clue about where it is looping. Diddling optimization options can also sometimes
provide a clue.

(Missed this earlier as the conversation moved off-list.)

And to keep the list abreast, this appears to be related to the long double
issue on powerpc where needed an extra #define to ensure compilation. That
commit is the difference in a bisection as I was able to demonstrate. The
issue can also be circumvented by disabling long double support on the
platform, but hopefully a better fix can be found.  Bryan Lewis was
eagle-eyed on this and very helpful. The issue is now back in the hands of R
Core and I and others will await the news.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org>
wrote:
>
>
> On 29 April 2020 at 11:22, peter dalgaard wrote:
> | Hum, at least it is not Apple, so maybe you can attach a debugger to the
running process? (gdb -p process_id or something like that --- haven't
actually done it for a decade). Then at least we can get a stack trace and a
clue about where it is looping. Diddling optimization options can also sometimes
provide a clue.
>
> (Missed this earlier as the conversation moved off-list.)
>
> And to keep the list abreast, this appears to be related to the long double
> issue on powerpc where needed an extra #define to ensure compilation. That
> commit is the difference in a bisection as I was able to demonstrate. The
> issue can also be circumvented by disabling long double support on the
> platform, but hopefully a better fix can be found.  Bryan Lewis was
> eagle-eyed on this and very helpful. The issue is now back in the hands of
R
> Core and I and others will await the news.
Which reminds me that [1] was required for v3.6.2. Could be related?

[1]
https://src.fedoraproject.org/rpms/R/blob/master/f/R-3.6.2-ppc64-no-const-long-double.patch

I?aki

On 30 April 2020 at 09:42, I?aki Ucar wrote:
| On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org>
wrote:
| > And to keep the list abreast, this appears to be related to the long
double
| > issue on powerpc where needed an extra #define to ensure compilation.
That
[...]
| Which reminds me that [1] was required for v3.6.2. Could be related?

Yes, that is what I refered to via "long double issue on powerpc".
Without a
URL but it is the same issue (in the sense of that architecture being "very
different"); it simply is no longer the same issue of needing the #define
to
compile. But the diffferent nature of powerpc now bite's R own
'compiler'
package.  R Core is on it; I may avoid it in a quicker fix by disabling long
double support on just this platform (til we have a better fix).

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org