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
Comment on attachment 260313 [details] devel/alire: Update to 2.1.0 bug #287458
(In reply to Alastair Hogge from comment #29) Are you trying to say that you also give up on devel/alire?
Hello, I don't want to intrude and would happily let Alastair or anyone else take care of it (maybe alire was voluntarily left out of bug #287458?), but if nobody else is interested I'd like to try making this update happen. I don't know much about FreeBSD internals, I've only maintained a few easy ports, but I have hardware access and I'm a long-time Ada user and sad of not being able to use it anymore on my favorite OS.
(In reply to Natacha Porté from comment #31) Feel free to do so! Please read the other comments on this bug report for the open issues. You don't have to solve them necessarily, but it would be great if you could do so.
On my FreeBSD 15.0 amd64 it builds fine... do we have problems on other platforms?
(In reply to Marcin Cieślak from comment #33) Since bug #286795 is fixed, I expect the build to work as well on all platforms, but maybe someone with hardware (like fuz@) might want to double-check. I wanted to check it actually works before submitting the patch here, but I have some unrelated issues and haven't yet found the time to use it. On the other hand, I don't think a broken alire 2.1 is worse than a working alire 1.2, so if it builds satisfactorily I don't mind it being committed (and I can take over maintainership while there (unless Alaister still wants it)).
Hi All, I did build latest ALire 2.1.0 on FreeBSD 14.3 some days ago. It is now part of the whole Ada toolchain I build with poudriere on a dedicated FBSD build server for AdaForge.org https//adaforge.org I had to tweek a bit the *.GPR build files of dependencies (submodules). All the ALire build is done exclusively with 'gprbuild' - no use of ALire make files. Next step : adapt my automated build script to produce a compatible FBSD port/pkg asset. I'd like to sync this work with what Alastair, Natacha & al. has already done on this topic. You will find sources and signed binaries on AdaForge GitLab : * Latest Ada (GNAT FSF) compiler front-end for GCC : gnat2022-15.1.1 binaries * https://gitlab.com/adaforge/devtools/ada-compilers/freebsd-ada-compilers/GNAT-2022/-/packages/42520000 gcc (built by AdaForge, latest Ada commit on 2025-07-04) 15.1.1 20250706 Copyright (C) 2025 Free Software Foundation, Inc. GNAT 15.1.1 20250706 Copyright (C) 1996-2025, Free Software Foundation, Inc * (GNAT FSF) Ada source project-build tool : gprbuild-2025.3.0 binaries * https://gitlab.com/adaforge/devtools/buildtools/AdacDevtBuilGPRb/-/packages/42568547 GPRBUILD FSF 2025.3 (built by AdaForge) (x86_64-unknown-freebsd14.3) Copyright (C) 2004-2025, AdaCore * (ALIRE ASL2) Ada Library manager & Repository = ALire : alire-2.1.0 binaries * https://gitlab.com/adaforge/devtools/buildtools/MostDevtBuilALire/-/packages/42513390
Note about FreeBSD on aarch64, I have to set-up a QEMU with gnat. Summer holidays for now. Will do the set-up end of august.
^Triage: what is the status of this PR? As of today, there are no valid patches for the automation to try to process.
I hope I'm not disturbing the triage process with my non-answer. The original patch from Alastair (deleted in comment #29) used to work on amd64 (on my computer and in comment #33) and probably still works or almost (I haven't tried recently). I really don't know why Alastair deleted it, maybe to force a new patch that includes maintainer update? Then William mentioned having working (and tested?) builds not only on amd64 but on other platforms as well, so I hoped he would contribute his ports instead of the original deleted patch. So at this point we can either wait and hope some more, or bring back Alastair's original patch and see how it fares on tier 1 platforms. I don't have a strong opinion either way, alire 1.2 is useless so even a partially-working 2.1 update is better, but I'm not sure even a perfectly-working alire 2.1 would do much good without William's updates to other ports. (For context, alire is a language-specific package manager, and William's updates include a non-obsolete version of the compiler.) Anybody wants to push one way or the other?
This has been going on for so long that I lost track of the current status of affairs. Alastair seems to not have time for FreeBSD, so do whatever is needed to get the port back on track.
Created attachment 268410 [details] alire 2.1.0 patch An slightly updated patch from Alistair. Removed USE_GCC, also switched from the DEBUG option to WITH_DEBUG feature. I have managed to build and test it on a real arm64 machine as well. It build with the current gnat12 from ports without problems now (thanks Natacha for fixing the plist issue).
Alastair, sorry for the typo. There will be more work make alire useful, but this port can be updated. Most importantly we should try to push some changes to the repository to make things work on FreeBSD. For example GNU make https://github.com/alire-project/alire/issues/2054, m4 --version problem etc. But the basics (gprbuild, gnat) do seem to work.
Created attachment 268442 [details] Update to 2.1.0 * Integrate tests * 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} * Reset ${MAINTAINER} * 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
(In reply to Natacha Porté from comment #38) I obsoleted the original 2.1.0 patch because the testing was not finished. It is now integrated, tho many tests are skipped. The current 2.1.0 patch, requires a new testing dependency bug #293521. Sorry for not resetting the ${MAINTAINER}.
Great work, hope the e3 test gets merged soon. Do you think we could use WITH_DEBUG=yes instead of a separate option? I am also not sure if we need USE_GCC
(In reply to Marcin Cieślak from comment #44) > Great work, hope the e3 test gets merged soon. It will probably be all you get for sometime. > Do you think we could use WITH_DEBUG=yes instead of a separate option? Sorry Marcin, I forgot to include that change. I do not understand the mechanics of it, and I am not against it. > I am also not sure if we need USE_GCC I think I included that change of yours, and poudriere-testport was OK, and usage of alr on 16-CURRENT was without issues. I also dropped the hard requirement on GNAT-12 in that area too, since the Ada Ports' USES framework no longer defaults to gcc6-aux. Also, I must apologies again, I forgot to attribute you in the commit message of my last patch, sorry.
Please no need to aplogize. Your patch is working and this is the most important thing. I do not need any attribution for this, thank you. make WITH_DEBUG=yes is "the" way to add debugging flags to the build. For C/C++ it adds "-g" It's all in here https://cgit.freebsd.org/ports/tree/Mk/Features/debug.mk The arcane incantation :${xxx:Urelease:Ddebug} shall mean "release" when xxx is undefined, "debug" when xxx is defined. A oneliner instead of .if/else