Dirk Eddelbuettel
2020-Apr-30 00:49 UTC
[Rd] 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
IƱaki Ucar
2020-Apr-30 07:42 UTC
[Rd] R 4.0.0 build error with sysdata.rda on ppc64el architecture
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
Dirk Eddelbuettel
2020-Apr-30 13:22 UTC
[Rd] R 4.0.0 build error with sysdata.rda on ppc64el architecture
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
Maybe Matching Threads
- R 4.0.0 build error with sysdata.rda on ppc64el architecture
- [External] Re: R 4.0.0 build error with sysdata.rda on ppc64el architecture
- [External] Re: R 4.0.0 build error with sysdata.rda on ppc64el architecture
- R 4.0.0 build error with sysdata.rda on ppc64el architecture
- R 4.0.0 build error with sysdata.rda on ppc64el architecture