Build fails on Fedora Rawhide ppc64le
I maintain the golang-modernc-sqlite package on Fedora. Building version 1.34.4 of the package on Rawhide fails with this error on ppc64le:
modernc.org/sqlite/vfs
# modernc.org/sqlite/vfs [modernc.org/sqlite/vfs.test]
./vfs_linux_ppc64le.go:1327:44: cannot use uint32(294) (constant 294 of type uint32) as int32 value in argument to libc.X__assert_fail
FAIL modernc.org/sqlite/vfs [build failed]The build works fine on Rawhide aarch64 and x86_64. The build worked fine on all architectures on Fedora 41.
Activity
@flyn.org Thanks for the report!
Cannot reproduce on Debian:
debian@sqlite1:~/src/modernc.org/sqlite$ git checkout v1.34.4 Note: switching to 'v1.34.4'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example: git switch -c <new-branch-name> Or undo this operation with: git switch - Turn off this advice by setting config variable advice.detachedHead to false HEAD is now at d3e8a66 retract v1.34.3 debian@sqlite1:~/src/modernc.org/sqlite$ git status HEAD detached at v1.34.4 nothing to commit, working tree clean debian@sqlite1:~/src/modernc.org/sqlite$ git log -1 commit d3e8a664e8b51225de529ad17338007b5f16c5df (HEAD, tag: v1.34.4) Author: Jan Mercl <0xjnml@gmail.com> Date: Fri Dec 20 12:40:40 2024 +0100 retract v1.34.3 debian@sqlite1:~/src/modernc.org/sqlite$ go build -v ./... modernc.org/sqlite/lib modernc.org/sqlite/vfs modernc.org/sqlite modernc.org/sqlite/examples/example1 debian@sqlite1:~/src/modernc.org/sqlite$ git checkout v1.34.5 Previous HEAD position was d3e8a66 retract v1.34.3 HEAD is now at 15818ab move the vendor tool into a separate module, updates gc#3 debian@sqlite1:~/src/modernc.org/sqlite$ git log -1 commit 15818ab7fe22935c740f0bf5069901a1314799d0 (HEAD, tag: v1.34.5, origin/master, origin/HEAD, master) Author: Jan Mercl <0xjnml@gmail.com> Date: Sun Jan 12 15:54:40 2025 +0100 move the vendor tool into a separate module, updates gc#3 debian@sqlite1:~/src/modernc.org/sqlite$ go build -v ./... modernc.org/sqlite/examples/example1 debian@sqlite1:~/src/modernc.org/sqlite$ go version go version go1.23.5 linux/ppc64le debian@sqlite1:~/src/modernc.org/sqlite$ uname -a Linux sqlite1 5.10.0-32-powerpc64le #1 SMP Debian 5.10.223-1 (2024-08-10) ppc64le GNU/Linux debian@sqlite1:~/src/modernc.org/sqlite$Is it possible this applies?
assigned to @cznic
I missed the documentation about the fragile dependencies. I was building sqlite 1.34.4 against libc 1.61.6, even though sqlite's go.mod called for libc 1.55.3. Changing this allowed the package to build on all of Fedora Rawhide's primary architectures. Thanks!
Would it be possible to reset sqlite to the latest libc? What factors in sqlite lead you to adopt a new libc revision? Do you try to keep sqlite up-to-date with libc, or is this not a goal? Just trying to understand from a packager's point of view.
-
What factors in sqlite lead you to adopt a new libc revision?
Do you mean "not to adopt"? The answer is simple, modernc.org/sqlite is stuck on modernc.org/libc@v1.55.3 because sqlite tests do not pass with newer linux libc versions, based on musl, at linux/arm. I was not yet able to find and fix the problem after multiple attempts. The same musl sources and the same mechanism is used for all other linux targets and it works well everywhere else. The obvious difference is that it's a 32 bit target, but linux/386 works fine. It can be a bug in ccgo/v4, but I don't know yet. IIRC, all 64 bit linux targets were already musl based in libc@v1.55.3.
The sqlite tests are written in Tcl, not C, and following the path Tcl script -> Tcl C interpreter -> Tcl C interpreter transpiled to Go -> SQLite C transpiled to Go -> musl C transpiled to Go is not really easy. My free time is also limited. So here we are, 6 minor libc versions later, still unresolved.
Every other transpiled C projects I use imports the latest libc also on linux/arm and does pass tests. I don't know what is so specifically different for SQLite, unfortunately.
Do you try to keep sqlite up-to-date with libc, or is this not a goal?
Of course, that what I'm trying to achieve for the last few months ;-)
There seems to have been an attempt to manage this issue with a sqlite-internal libc (commit #8794efa6, use internal/libc). But that was later retracted with commit #ad49d64f. Is there documentation about why this did not work or was not satisfactory? Now I am thinking about how to manage this in the Fedora packages.
-
8794efa6 was a big mistake, to say it politely. I somehow completely forgot that users of this package sometimes need to import also modernc.org/libc additionaly to modernc.org/sqlite. After reports started to appear about broken builds/CI, ad49d64f repaired the damage.
I hope to have some time for a linux/arm debugging session this weekend and look into the stuck libc issue again.
mentioned in commit libc@b95a4b07
-
@flyn.org Got lucky and found one bug that affects 32 bit musl-based targets. linux/386 fixed in libc@b95a4b07, linux/arm is the next.
This per se does not resolve #177 (closed) yet, but the bug was causing passing 64 bit arguments to kernel syscalls wrong. Not only was the upper 32 bits lost, any following argument went into a wrong ABI slot.
We will see, provided the new commits pass tests with libz and libtcl8.6, if it possibly fixes #177 (closed) as well and libsqlite3 can then catch up with latest libc version as intended.
mentioned in commit libc@a973ec1d
-
@flyn.org FYI, AFAICT, the newset libc@v1.61.12 is probably now finally ready for this package. It must first pass tests in the libsqlite3 repository. Once that happens it will be vendored into this repo.
We are missing one builder since February 4th (loong64). If it does not come back next week, I'll try to contact the machine owners. It is a supported target and we need it vetoing our commits not only for this package.
-
@flyn.org sqlite@v1.35.0 was just tagged. AFAICT, the libc version issue is now resolved. Please try your packaging and let me know if it works for you, thanks.
You seem to have fixed the problem!
https://koji.fedoraproject.org/koji/taskinfo?taskID=129206684
Thank you!
mentioned in issue tcl#6
