search

AdaCore / gprbuild

GPRbuild is an advanced build system designed to help automate the construction of multi-language systems.
Other
65 stars 21 forks source link

Constraint_Error in GPRinstall on s390x #95

Closed Rombobeorn closed 2 years ago

Rombobeorn commented 3 years ago

GPRinstall fails with Constraint_Error only on s390x when building Gnatcoll-DB 21.0.0 with GPRbuild 2020 on what will become Fedora 34.

gprinstall -P sql/gnatcoll_sql.gpr -aP stage/usr/share/gpr --prefix=/builddir/build/BUILD/gnatcoll-db-21.0.0/stage/usr --lib-subdir=/builddir/build/BUILD/gnatcoll-db-21.0.0/stage/usr/lib64 --ali-subdir=/builddir/build/BUILD/gnatcoll-db-21.0.0/stage/usr/lib64/gnatcoll_sql --no-lib-link -m --create-missing-dirs raised CONSTRAINT_ERROR : gpr-env.adb:2252 range check failed Exception CONSTRAINT_ERROR raised, while processing project file gprinstall: "sql/gnatcoll_sql.gpr" processing failed

Removing -aP avoids the Constraint_Error when processing gnatcoll_sql, but then the same error happens later when GPRinstall tries to install gnatcoll_sqlite:

gprinstall -P sqlite/gnatcoll_sqlite.gpr --prefix=/builddir/build/BUILD/gnatcoll-db-21.0.0/stage/usr --lib-subdir=/builddir/build/BUILD/gnatcoll-db-21.0.0/stage/usr/lib64 --ali-subdir=/builddir/build/BUILD/gnatcoll-db-21.0.0/stage/usr/lib64/gnatcoll_sqlite --no-lib-link -m --create-missing-dirs raised CONSTRAINT_ERROR : gpr-env.adb:2252 range check failed Exception CONSTRAINT_ERROR raised, while processing project file gprinstall: "sqlite/gnatcoll_sqlite.gpr" processing failed

Perhaps it's triggered when GPRinstall doesn't find gnatcoll_sql.gpr because stage/usr/share/gpr is missing from the search path?

Rombobeorn commented 3 years ago

See also https://bugzilla.redhat.com/show_bug.cgi?id=1905708

anisimkov commented 3 years ago

What is the current directory ?

Rombobeorn commented 3 years ago

anisimkov wrote:

What is the current directory ?

GPRinstall is invoked with a current working directory of /builddir/build/BUILD/gnatcoll-db-21.0.0 in this case.

The build is done with Mock, which I think uses chroot, so the pathname is longer when seen from outside the chroot environment, but GPRinstall shouldn't need to know about that.

anisimkov commented 3 years ago

Where is the GNAT in this chroot environment ?

anisimkov commented 3 years ago

I guess you have access to GNAT Pro, right ? If so I suggest to check your reproducer on gnat Pro 21.1. There is some fix near the exception raised in 21.1.

Rombobeorn commented 3 years ago

anisimkov wrote:

Where is the GNAT in this chroot environment ?

Mock installs the required RPM packages, so everything is supposed to be in the same places as in a normal Fedora system.

Here's the list of files in the package gcc-gnat: https://koji.fedoraproject.org/koji/rpminfo?rpmID=25015158 There are the various /usr/bin/gnat* programs, and /usr/libexec/gcc/s390x-redhat-linux/11/gnat1 for example. I don't see anything obviously wrong, but apparently something is different on s390x compared to all the other architectures.

Here are the main gcc package and gprbuild if you want to see those: https://koji.fedoraproject.org/koji/rpminfo?rpmID=25015141 https://koji.fedoraproject.org/koji/rpminfo?rpmID=25019585

I guess you have access to GNAT Pro, right ?

Not that I'm aware of. I don't have a mainframe at home either. Fedora's build servers run only what's packaged in Fedora, and I can't log in and poke around in those. It may be possible to get shell access to some s390x system, but I'm not sure.

anisimkov commented 3 years ago

I suggest try to get gprbuild sources from github and rebuild it to see is the error exists in git HEAD.

landgraf commented 3 years ago

Hi there!

Not that I'm aware of. I don't have a mainframe at home either. Fedora's build servers run only what's packaged in Fedora, and I can't log in and poke around in those. It may be possible to get shell access to some s390x system, but I'm not sure.

I reproduced this bug without mock involved on s390x few weeks ago and played with gdb a bit without success. The bug was reproducible only on s390x and only if ADA_PROJECT_PATH variable was set (doesn't matter which value it had). I'll try to find time and mainframe to check newer revisions.

landgraf commented 3 years ago

update: Looks like our s390x fedora lpars are on maintenance for some time...

t-14 commented 2 years ago

Looks like it's hard to make progress on this given environment restrictions. If this can be reproduced using a less exotic environment, we'll take a look.