R 4.0.0 build error with sysdata.rda on ppc64el architecture

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

R 4.0.0 build error with sysdata.rda on ppc64el architecture

Dirk Eddelbuettel

The R 4.0.0 package migration on Debian is being held back by a failed build
on ppc64el [1]. We can see from the history of builds logs [2] that it used
to build, briefly failed, worked again and then failed leading to R 4.0.0's
release. (And my bad for missing how the alpha1/alpha2/beta/rc builds failed.)

I have however neither changed anything, nor did I ever have to accomodate
ppc64el (as it has happened with other platforms in the past).

The automated build gets killed after 150 mins at

make[7]: Entering directory '/<<PKGBUILDDIR>>/src/library/tools/src'
mkdir -p -- ../../../../library/tools/libs
make[7]: Leaving directory '/<<PKGBUILDDIR>>/src/library/tools/src'
make[6]: Leaving directory '/<<PKGBUILDDIR>>/src/library/tools/src'
make[5]: Leaving directory '/<<PKGBUILDDIR>>/src/library/tools'
make[5]: Entering directory '/<<PKGBUILDDIR>>/src/library/tools'
installing 'sysdata.rda'
E: Build killed with signal TERM after 150 minutes of inactivity

as can be seen in [3]. The Debian wiki has pointers for getting a shell
account on such platforms [4] (and that is not limited to Debianers but a
'Minipower' service).  I now have one such account on the VM farm at Unicamp
[5] in Brazil. It uses OpenStack (slick, never used it before) and I just
provisioned a reasonably beefy machine, booted from one of the available OSs
(Ubuntu 20.04), installed the build-dependencies and ... am now hanging at
the exact same spot:

make[7]: Entering directory '/home/ubuntu/git/r-base/src/library/tools/src'
mkdir -p -- ../../../../library/tools/libs
make[7]: Leaving directory '/home/ubuntu/git/r-base/src/library/tools/src'
make[6]: Leaving directory '/home/ubuntu/git/r-base/src/library/tools/src'
make[5]: Leaving directory '/home/ubuntu/git/r-base/src/library/tools'
make[5]: Entering directory '/home/ubuntu/git/r-base/src/library/tools'
installing 'sysdata.rda'

So at least it reproduces. But how do we go about addressing this? Why would
it be looping infinitely trying to assemble sysdata.rda?

Any hints or suggestions or debug flags I should set?

Thanks in advance for any pointers,  Dirk


[1] https://buildd.debian.org/status/package.php?p=r-base&suite=experimental
[2] https://buildd.debian.org/status/logs.php?pkg=r-base&arch=ppc64el
[3] https://buildd.debian.org/status/fetch.php?pkg=r-base&arch=ppc64el&ver=4.0.0-1&stamp=1587737274&raw=0
[4] https://wiki.debian.org/ppc64el
[5] https://openpower.ic.unicamp.br/minicloud/

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.0 build error with sysdata.rda on ppc64el architecture

Peter Dalgaard-2
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.

-pd

> On 29 Apr 2020, at 01:17 , Dirk Eddelbuettel <[hidden email]> wrote:
>
>
> The R 4.0.0 package migration on Debian is being held back by a failed build
> on ppc64el [1]. We can see from the history of builds logs [2] that it used
> to build, briefly failed, worked again and then failed leading to R 4.0.0's
> release. (And my bad for missing how the alpha1/alpha2/beta/rc builds failed.)
>
> I have however neither changed anything, nor did I ever have to accomodate
> ppc64el (as it has happened with other platforms in the past).
>
> The automated build gets killed after 150 mins at
>
> make[7]: Entering directory '/<<PKGBUILDDIR>>/src/library/tools/src'
> mkdir -p -- ../../../../library/tools/libs
> make[7]: Leaving directory '/<<PKGBUILDDIR>>/src/library/tools/src'
> make[6]: Leaving directory '/<<PKGBUILDDIR>>/src/library/tools/src'
> make[5]: Leaving directory '/<<PKGBUILDDIR>>/src/library/tools'
> make[5]: Entering directory '/<<PKGBUILDDIR>>/src/library/tools'
> installing 'sysdata.rda'
> E: Build killed with signal TERM after 150 minutes of inactivity
>
> as can be seen in [3]. The Debian wiki has pointers for getting a shell
> account on such platforms [4] (and that is not limited to Debianers but a
> 'Minipower' service).  I now have one such account on the VM farm at Unicamp
> [5] in Brazil. It uses OpenStack (slick, never used it before) and I just
> provisioned a reasonably beefy machine, booted from one of the available OSs
> (Ubuntu 20.04), installed the build-dependencies and ... am now hanging at
> the exact same spot:
>
> make[7]: Entering directory '/home/ubuntu/git/r-base/src/library/tools/src'
> mkdir -p -- ../../../../library/tools/libs
> make[7]: Leaving directory '/home/ubuntu/git/r-base/src/library/tools/src'
> make[6]: Leaving directory '/home/ubuntu/git/r-base/src/library/tools/src'
> make[5]: Leaving directory '/home/ubuntu/git/r-base/src/library/tools'
> make[5]: Entering directory '/home/ubuntu/git/r-base/src/library/tools'
> installing 'sysdata.rda'
>
> So at least it reproduces. But how do we go about addressing this? Why would
> it be looping infinitely trying to assemble sysdata.rda?
>
> Any hints or suggestions or debug flags I should set?
>
> Thanks in advance for any pointers,  Dirk
>
>
> [1] https://buildd.debian.org/status/package.php?p=r-base&suite=experimental
> [2] https://buildd.debian.org/status/logs.php?pkg=r-base&arch=ppc64el
> [3] https://buildd.debian.org/status/fetch.php?pkg=r-base&arch=ppc64el&ver=4.0.0-1&stamp=1587737274&raw=0
> [4] https://wiki.debian.org/ppc64el
> [5] https://openpower.ic.unicamp.br/minicloud/
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: [hidden email]  Priv: [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.0 build error with sysdata.rda on ppc64el architecture

Dirk Eddelbuettel

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 | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.0 build error with sysdata.rda on ppc64el architecture

Iñaki Ucar
On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R 4.0.0 build error with sysdata.rda on ppc64el architecture

Dirk Eddelbuettel

On 30 April 2020 at 09:42, Iñaki Ucar wrote:
| On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <[hidden email]> 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 | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [External] Re: R 4.0.0 build error with sysdata.rda on ppc64el architecture

luke-tierney
On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote:

>
> On 30 April 2020 at 09:42, Iñaki Ucar wrote:
> | On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <[hidden email]> 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).

Maybe I missed something. How is the 'compiler' package involved?

Best,

luke

>
> Dirk
>
>

--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:   [hidden email]
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [External] Re: R 4.0.0 build error with sysdata.rda on ppc64el architecture

Peter Dalgaard-2
I don't think compiler was involved, it was just the next thing after sysdata.rda, so a suspect at some point.

-pd

> On 30 Apr 2020, at 16:11 , [hidden email] wrote:
>
> On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote:
>
>>
>> On 30 April 2020 at 09:42, Iñaki Ucar wrote:
>> | On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <[hidden email]> 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).
>
> Maybe I missed something. How is the 'compiler' package involved?
>
> Best,
>
> luke
>
>>
>> Dirk
>>
>>
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa                  Phone:             319-335-3386
> Department of Statistics and        Fax:               319-335-3017
>   Actuarial Science
> 241 Schaeffer Hall                  email:   [hidden email]
> Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: [hidden email]  Priv: [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [External] Re: R 4.0.0 build error with sysdata.rda on ppc64el architecture

Dirk Eddelbuettel
In reply to this post by luke-tierney

On 30 April 2020 at 09:11, [hidden email] wrote:
| On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote:
| Maybe I missed something. How is the 'compiler' package involved?

See the other email thread; you replied (~ 26 hours ago) to my message adding
that "sysdata.rda in 'tools' hanging was wrong". It gets to the next stage,
which is 'compiler'.

We know by now (thanks to Bryan and Tomas) that src/main/machar.c is the real
culprit due to the long double behaviour on ppc64el.  I presume 'compiler'
calls into platform.c and hence machar.c for calibration or setup.

On the Debian side, I just shipped an updated source package which will skip
long double support on this platform.  That should allow builds to complete,
hopefully, so that we can look into get the build from 'experimental' into
'unstable' and the distro proper.  In the meantime, there are alternative
venues for getting R 4.0.0 binaries for Debian and Ubuntu as previously
mentioned.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [External] Re: R 4.0.0 build error with sysdata.rda on ppc64el architecture

Tomas Kalibera
On 4/30/20 4:37 PM, Dirk Eddelbuettel wrote:

> On 30 April 2020 at 09:11, [hidden email] wrote:
> | On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote:
> | Maybe I missed something. How is the 'compiler' package involved?
>
> See the other email thread; you replied (~ 26 hours ago) to my message adding
> that "sysdata.rda in 'tools' hanging was wrong". It gets to the next stage,
> which is 'compiler'.
>
> We know by now (thanks to Bryan and Tomas) that src/main/machar.c is the real
> culprit due to the long double behaviour on ppc64el.  I presume 'compiler'
> calls into platform.c and hence machar.c for calibration or setup.

Yes, R just hangs during startup, always, it is not related to the
compiler nor sysdata.rda.
The problem is that machine characteristics detection does not work with
long double on ppc64el, it falls into an infinite loop.

Tomas

>
> On the Debian side, I just shipped an updated source package which will skip
> long double support on this platform.  That should allow builds to complete,
> hopefully, so that we can look into get the build from 'experimental' into
> 'unstable' and the distro proper.  In the meantime, there are alternative
> venues for getting R 4.0.0 binaries for Debian and Ubuntu as previously
> mentioned.
>
> Dirk
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: [External] Re: R 4.0.0 build error with sysdata.rda on ppc64el architecture

Kirill Maslinsky
In reply to this post by Dirk Eddelbuettel

Dirk Eddelbuettel writes:

> We know by now (thanks to Bryan and Tomas) that src/main/machar.c is the real
> culprit due to the long double behaviour on ppc64el.  I presume 'compiler'
> calls into platform.c and hence machar.c for calibration or setup.
>
> On the Debian side, I just shipped an updated source package which will skip
> long double support on this platform.  That should allow builds to complete,
> hopefully, so that we can look into get the build from 'experimental' into
> 'unstable' and the distro proper.

I had the similar issue on ppc64le when trying to package R 4.0.0 for ALT
Linux Sisyphus. Disabling long double support indeed fixes the build of
the binaries, but then the build fails in the tests section (make check)
with violated assertions in some basic tests results.

Do you also have this problem, and is there a better solution to this
issue on ppc64le yet?

--
KM

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel