Arch Linux User Repository

hi @wvxvw

Apologies for these problems.

Can you please try the following ...

$ pamac build gprbuild-bootstrap
$ pamac build xmlada
$ pamac build gprbuild gprbuild-toolbox

I've also redirected the doc build output to a log file.

Also, the Ada packages are now available in an unofficial Arch repository.

https://wiki.archlinux.org/title/Unofficial_user_repositories

Thanks for reporting.

Regards.

This package is available in the Arch Ada Repository.

https://wiki.archlinux.org/title/Unofficial_user_repositories

The package build fails with the following message: ==> Connecting to GIT server.... You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch>

The obsolete 'Makefile.archy' file has been removed, along with all references to it. Should build ok now.

Makefile.archy needs to be added to the src array in the PKGBUILD.

Earnest, Apologies for the delay. I've been waiting for GNAT GPL16 to emerge before tackling the archy Ada updates. (Also been a bit flat out.) "... a malicious user can dump a gcc or clang script in some bin directory prepended to PATH and gprbuild will blindly use it." I didn't know of this problem. Thanks for pointing it out. "... they're going to add a standalone static gprbuild binary which should help bootstrapping in the 2016 release." This they have done. You're 'whining' has done some good ! ... :) . Yes, it should help simplify things considerably. "... my approach is to build gprbuild using the static gprbuild, which also builds xmlada ..." I will try to do the same. "... they've at least added checksums for their over-http downloads." Again, this they have done :) . Sincere thanks for your comments (and successful efforts to improve the Ada ecosystem). My impression is that AdaCore is largely resistant to outside influences, so your efforts are doubly appreciated. cheers, charlie5.

I've tried working with upstream Adacore to fix this build system and it's hopeless. They refuse to move from Debianisms and employ very sketchy practices such as rolling over PATH to find tools. This NIH could be solved nicely by honouring de facto environments such as CC but no, instead a malicious user can dump a gcc or clang script in some bin directory prepended to PATH and gprbuild will blindly use it. They also offer no way to bootstrap gprbuild (other build systems, such as make, don't seem to suffer from this insanity). Up until now they've only provided a static gprbuild as part of their giant 300+MiB download, although thanks to my whining they're going to add a standalone static gprbuild binary which should help bootstrapping in the 2016 release. Speaking of bootstrapping, my approach is to build gprbuild using the static gprbuild, which also builds xmlada (PKGBUILD: <https://ptpb.pw/UGfU/sh>). Then this gprbuild is used to build xmlada (PKGBUILD: <https://ptpb.pw/Tk_k/sh>) proper and then the final gprbuild (PKGBUILD: <https://ptpb.pw/YP6n/sh> (incomplete)). At this point gprbuild will also provide gprbuild-bootstrap as a virtual package so any subsequent rebuilds can use it instead of going through the static one. * https://github.com/AdaCore/gprbuild/issues/2 * https://github.com/AdaCore/xmlada/issues/1 * https://github.com/AdaCore/xmlada/issues/2 Hopefully this can help to verify the initial compiler wasn't malicious IIRC <http://www.dwheeler.com/trusting-trust/> as Adacore do not sign their downloads, although again thanks to my whining they've at least added checksums for their over-http downloads. Either way, Adacore is a miserable clusterfuck and the only way to make gprbuild and the Ada library ecosystem work on non-Debian distributions is to patch/fork gprbuild. (Or hope people who write Ada software are wise enough to also provide Makefiles, but fat chance of that happening.)

"Perhaps it would be better to patch gprbuild to change the path it uses?" ... a better option, yes. In fact, the gcc/gnat/gprbuild and gnat_util (which requires full gcc-ada rebuild) is, err, tricky, to sort out. There are also later issues with gdb not recognising Ada exceptions (such as Constraint_Error) when you want to set break point on a given exception, perhaps due to the gcc/gnat runtime not being built with debug symbols attached (i guess). I, err, sort of inherited this job (so am glad of any help/advice). I will try it locally, of course.

Installing that package works, though it is imperfect. Perhaps it would be better to patch gprbuild to change the path it uses? I haven't looked at how difficult that would be.

I guess PKGBUILD depends settings musyt need attention ... will look properly tomorrow. Sorry for inconvenience.

Ah, Have you installed the 'prepare_gnat_util' package ? (It should provide the libgnat-5.3.0 link). As you say, hackish ... any advice welcome.

@charlie5 It shows "gcc (GCC) 5.3.0" The library seems to be named /usr/lib/libgnat-5.so rather than /usr/lib/libgnat-5.3.so like it is looking for. A symlink makes it compile, but that is a hack.