The OCaml 5.2 build is ongoing.
flocq FTBFS on ppc64le (only) with a stack overflow:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2458620
I tried increasing the stack size in case it was just marginal, but to no effect.
I have reserved a ppc64le system so I can take a look at this tomorrow. Let's see if I can at least get a stack trace.
This unfortunately affects several other packages:
- gappalib-coq - why3 - frama-c
Rich.
On Wed, May 29, 2024 at 11:44:48PM +0100, Richard W.M. Jones wrote:
The OCaml 5.2 build is ongoing.
flocq FTBFS on ppc64le (only) with a stack overflow:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2458620
Since flocq seems to have no public bug tracker, I might as well write my findings here ...
I believe the error is raised in this code:
https://github.com/coq/coq/blob/ac1e5ebd3f50a53b46cdb59225887841f5d24d02/coq...
I had a lot of trouble getting gdb to understand /usr/bin/coqc. Is it even a native code binary? As I couldn't place a breakpoint, I trapped on write system calls to fd=2, but no useful stack trace was forthcoming. I wonder if it's even a real stack overflow or some stack inside the parser?
However I did observe that /usr/bin/coqc.byte does not have the same problem (so perhaps it is the real stack). I added this very ugly workaround to get it to compile:
https://src.fedoraproject.org/rpms/flocq/c/c46c3bb8222dca716316841514ce91e86...
Also of note: OCaml 5.2 re-enables the ppc64le native code generator, which was previously disabled since OCaml 5, so perhaps this is a new bug in the OCaml compiler?
I tried increasing the stack size in case it was just marginal, but to no effect.
I have reserved a ppc64le system so I can take a look at this tomorrow. Let's see if I can at least get a stack trace.
This unfortunately affects several other packages:
- gappalib-coq
- why3
- frama-c
I will re-enable these now and try to build them.
Rich.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, May 30, 2024 at 10:01:25AM +0100, Richard W.M. Jones wrote:
On Wed, May 29, 2024 at 11:44:48PM +0100, Richard W.M. Jones wrote:
The OCaml 5.2 build is ongoing.
The build is complete now. All 194 packages built, only flocq required an ugly hack.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-938c868961
Rich.
Sorry for the silence. I've been on vacation, returning to find a giant pile of work waiting for me. :-)
On Thu, May 30, 2024 at 3:01 AM Richard W.M. Jones rjones@redhat.com wrote:
Since flocq seems to have no public bug tracker, I might as well write my findings here ...
I believe the error is raised in this code:
https://github.com/coq/coq/blob/ac1e5ebd3f50a53b46cdb59225887841f5d24d02/coq...
I had a lot of trouble getting gdb to understand /usr/bin/coqc. Is it even a native code binary? As I couldn't place a breakpoint, I trapped on write system calls to fd=2, but no useful stack trace was forthcoming. I wonder if it's even a real stack overflow or some stack inside the parser?
However I did observe that /usr/bin/coqc.byte does not have the same problem (so perhaps it is the real stack). I added this very ugly workaround to get it to compile:
https://src.fedoraproject.org/rpms/flocq/c/c46c3bb8222dca716316841514ce91e86...
Also of note: OCaml 5.2 re-enables the ppc64le native code generator, which was previously disabled since OCaml 5, so perhaps this is a new bug in the OCaml compiler?
That would be my suspicion. I recently talked to OCaml upstream about a ppc64le code generation bug that I tripped over while attempting to update frama-c, and they mentioned that they were aware of a number of ppc64le bugs in 5.2.0. Hopefully 5.2.1 will sort many of them out.