Created attachment 249727 [details] Update to 2.0.1 Update to 2.0.1: * Increase build verbosity * Prefix Port with "ada-" * Remove pkg-plist, most of the contents is now covered by ${PORTDOCS}, the remaining 4 entries by ${PLIST_FILES} https://github.com/alire-project/alire/releases/tag/v2.0.0 https://github.com/alire-project/alire/releases/tag/v2.0.1
[TESTPORT] poudriere-testport devel/ada-alire: [TESTPORT] main-amd64-current: PASS [TESTPORT] 13_2-amd64-release: PASS [TESTPORT] 13_3-amd64-release: PASS [TESTPORT] 13_3-i386-release: PASS [TESTPORT] 14_0-amd64-release: PASS [TESTPORT] main-i386-current: FAIL [TESTPORT] 13_2-i386-release: FAIL [TESTPORT] 14_0-i386-release: FAIL
Do you know why the build fails on some platforms? Is this failure acceptable to you?
Comment on attachment 249727 [details] Update to 2.0.1 Will need to redo patch without the ada- prefix.
(In reply to Robert Clausecker from comment #3) Heya Robert, The failures shit me to tears. I first noticed this (2022/2023) when I started working on restoring Ada Ports that been removed back in 2022-02-28[1]. The failures were happening only on i386, with lang/gnat12, and devel/gprbuild. Using lang/gcc6-aux was OK, provided I could get the Port to build, however, many of those Ada systems have seen updated since they were last in the Ports tree, and I think they required a later version of an Ada compiler, as well as moving from gnatmake to gprbuild. The failure happens in the gprbuild phase, from memory, and it had something to do with blowing out the stack space of the gprbuild process. Investigating this is on my TODO list, I would prefer working Ports, even in light of the i386 architecture's coming departure. Having said that, I doubt I will get around to investigating that before we see i386 off. I even have a vague memory of my initial Alire Port working on all i386 releases at the time too, but I sat on the Port for so long, that by the time I submitted it for review, the i386 builds were failing. All Ada Ports using lang/gnat12 do this as far I can recall. I still have no working environment for Port shenanigans, unfortunate, 'tis doing my head in; I will be away soon, delaying the restoration of said shenanigans further. Thanks for your interest tho. 1: https://cgit.freebsd.org/ports/commit/?id=8e2a89b
Okay, as you wish. I understand that you do not want to have this committed at this time?
Note that devel/gprbuild currently also fails on arm64: error: "s-imgllli.ali" not found, "s-imgllli.ads" must be compiled error: "s-imgllli.ali" not found, "s-imgllli.ads" must be compiled gnatmake: *** bind failed. *** Error code 4
(In reply to Robert Clausecker from comment #6) Yes, I mistakenly believed language specific Ports should have a prefix, in this case "ada-", so I started to reflect that in updates I was working on previously, however, I have since been informed, that is not the convention, bug #277823, comment #8.
(In reply to Robert Clausecker from comment #7) Yeah I noticed that too, my plan has been to investigate that using the QEMU option in poudriere-devel.
Just found this is still open. What's the state of affairs here?
I am still in hardware hell; I think I am getting closer to completing my new build host. So still incapacitated somewhat.
Comment on attachment 249727 [details] Update to 2.0.1 Will update with a new patch for 2.0.2
Currently putting a diff thur the poudriere-testport challenges.
(In reply to Alastair Hogge from comment #13) Great! Once you upload it here, I'll do comprehensive build tests.
(In reply to Robert Clausecker from comment #14) Sorry, I had the diff ready for submission, then I remembered that I had been wanting to look at integrating the testing. So I am working on that now, it requires some updates to other Ports, and a new Port.
Created attachment 260313 [details] devel/alire: Update to 2.1.0 Update to 2.1.0: * Remove desktop-file-utils from ${USES}, because no MIME type is declared * Remove pkg-plist, replacing its contents with the dynamically generated ${PLIST_FILES}, and ${PORTDOCS} * Some port{clippy|fmt|lint} maintenance * Use ${MAKE_CMD} in the do-build target instead of hard-coding grpbuild https://github.com/alire-project/alire/releases/tag/v2.1.0
Integrating tests is taking longer than I would like. I will, continue working on the do-test target.
(In reply to Alastair Hogge from comment #16) Build fails on arm64 FreeBSD 14.2: /usr/local/gnat12/bin/gnatbind -o b__alr-main.adb /wrkdirs/usr/ports/devel/alire/work/alr-2.1.0/obj/alr-main.ali -Es -g -static -x -F=/tmp/GPR.46240/GNAT-TEMP-000068.TMP -O=/tmp/GPR.4516/GNAT-TEMP-000001.TMP error: "s-imfi128.ali" not found, "s-imfi128.ads" must be compiled gprbind: invocation of gnatbind failed 0 bind process
Hmmm So 128bit type support is missing..maybe? Could be a GNAT issue...maybe?
(In reply to Alastair Hogge from comment #19) No idea. If you want me to run additional tests, please let me know which ones.
(In reply to Robert Clausecker from comment #20) I am suspecting either, the current GNAT Ada toolchain is missing some ARM64 components, or, it needs to be updated. Debian has[1], what I suspect is needed for ARM64, however, it looks like they have GNAT-15, too. We have GNAT-13 in the Tree, I am not sure if it worth the time to test that. What do we do? Is it possible to commit the current Alire update, and I will create a new PR to investigate the missing 128bit Image support for ARM64? If we do the later, the complete build log might be handy.
The missing citation/reference for above is: https://sources.debian.org/src/gcc-arm-none-eabi/15:12.2.rel1-1/gcc/ada/libgnat/s-imfi128.ads/
Created attachment 260348 [details] alire-2.1.0 build log on arm64 FreeBSD 14.2 (xz compressed) (In reply to Alastair Hogge from comment #21) > What do we do? Is it possible to commit the current Alire update, and I will create a new PR to investigate the missing 128bit Image support for ARM64? If we do the later, the complete build log might be handy. That sounds fine with me. Perhaps you could also try to blindly apply Debian's patch and have me try to build again with gnat patched like this. See attachment for the build log.
(In reply to Robert Clausecker from comment #23) > Perhaps you could also try to blindly apply Debian's patch and have me try to build again with gnat patched like this. I can give it a go, tho, that might have to wait until the weekend. I remembered some similar PRs: * lang/gnat12: missing ali files for aarch64 (bug #279996) * lang/gnat12: missing ali files for aarch64 (bug #285387)
(In reply to Alastair Hogge from comment #24) Sure, take your time!
So this error triggered a deteriorating memory, the problem is already affecting the current Alire Port, and I had forgotten to create an PR for it. So I created a new PR to track this issue, bug #286795
(In reply to Robert Clausecker from comment #25) I am curious how Poudriere and emulators/qemu-user-static perform, and will first make an effort to configure, and run that.
Oh bottoms, I do not think Qemu User-Mode[1] supports ARM64 1: https://wiki.freebsd.org/QemuUserModeHowTo