Alire can't locate .alire/lib/gcc but it's here

General
1

Hi, I have issues installing adalang, to get access to gnatpp:

$ alr install libadalang_tools
gpr.gpr:21:17: unable to locate “/home/drm/.alire/lib/gcc”
gprbuild: *** compilation phase failed
error: Command [“gprbuild”, “-s”, “-j0”, “-p”, “-P”, “/home/drm/.local/share/alire/builds/libgpr_25.0.0_17669998/122833a0092e86037b2a3f2e6a36047ffe12c7002f796bb126a525ec15fdea94/gpr/gpr.gpr”] exited with code 4
error: Build failed, cannot perform installation

But “/home/drm/.alire/lib/gcc” already exists, and has all the needed permissions…

2

I don’t know as much about alire, but you didn’t mention anything besides permissions so just checking. Is it in your path? I think Alire checks the PATH variable and it’s own cache/toolchains folder for installations.

3

~/.alire/lib/gcc is a directory, which presumably contains some compiler-related stuff. Mine contains riscv64-elf/.

I tried that build here – hasn’t finished yet, but libgpr2_25.0.0 got built OK. No help to you, of course.

Execute permission on a directory means that it can be searched, I think.

4

Yes it is in Path. The command was alr install libadalang_tools and I posted the whole error message. the execute permission is on

5

Oh, I just got

warn: Replacing libadalang_tools=23.0.0 with libadalang_tools=25.0.0/src/lal_tools.gpr...
error: Alire.Milestones.Containers.Sets.First_Element: set is empty
error: alr encountered an unexpected error, re-run with -d for details.
error: error location: Call stack traceback locations:

Someone else got something like this recently???

6

Well, I’m not going to rebuild with -d as suggested, it’s started rebuilding from xmlada. Life’s too short.

7

I had to purge all of alire and reinstall it, then recompile adalang. Now gnatpp is there… but oh god that sucks, there’s not a single exemple in here, I personally find the --help option result unreadable. They should have made a TUI frontend. I can’t get any of gcc’s page on it either.

8

For future similar troubles I’d suggest to try and install to a clean prefix (with alr install --prefix=/path/to/new/prefix). This way at least you can rule out interactions with previously installed releases.