Package Details: gprbuild 2016-1

Git Clone URL: https://aur.archlinux.org/gprbuild.git (read-only)
Package Base: gprbuild
Description: Software tool designed to help automate the construction of multi-language systems
Upstream URL: http://www.adacore.com/gnatpro/toolsuite/gprbuild/
Licenses: GPL
Submitter: None
Maintainer: charlie5
Last Packager: charlie5
Votes: 13
Popularity: 0.037471
First Submitted: 2010-02-03 13:25
Last Updated: 2016-07-03 01:51

Required by (6)

Sources (3)

Latest Comments

charlie5 commented on 2016-06-06 00:15

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

ids1024 commented on 2016-06-05 16:37

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

charlie5 commented on 2016-06-01 09:32

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.




Earnest commented on 2016-05-15 12:53

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.)

charlie5 commented on 2016-02-01 08:04

"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.

ids1024 commented on 2016-02-01 05:48

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.

charlie5 commented on 2016-02-01 05:46

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

Sorry for inconvenience.

charlie5 commented on 2016-02-01 05:40

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.

ids1024 commented on 2016-02-01 04:54

@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.

charlie5 commented on 2016-02-01 00:32

Hi ids1024,

What does this show ?

$ gcc --version

All comments