Indexed compiler crate fails if dependencies shared (macOS/aarch64)

[simonjwright]

I have an index to support macOS and aarch64. The compiler crate is named gnat_macos_aarch64.

If I build alr from master or release/2.0, and select gnat and gprbuild from my index, then

• if I allow dependencies.shared to default to true (or set it), I get (several blank lines), then

  error: Alire.Crate_Configuration.Profile_Maps.Constant_Reference: key not in map
  error: alr encountered an unexpected error, re-run with -d for details.

• if I set dependencies.shared to false, the build proceeds OK.

Is it that alr isn't treating this compiler crate as a toolchain crate?

The stack dump at the exception (the build is from master) is

alire__crate_configuration__profile_maps__constant_reference__2 (in alr) (a-ciorma.adb:393)
alire__crate_configuration__build_profile (in alr) (alire-crate_configuration.adb:95)
alire__builds__hashes__compute__compute__add_profile.133 (in alr) (alire-builds-hashes.adb:104)
alire__builds__hashes__compute__compute.129 (in alr) (alire-builds-hashes.adb:237)
alire__builds__hashes__compute__compute__2.127 (in alr) (alire-builds-hashes.adb:282)
alire__roots__traverse___wrapped_statements__traverse_wrap.238 (in alr) (alire-roots.adb:1982)
alire__solutions__traverse__visit.206 (in alr) (alire-solutions.adb:1482)
alire__solutions__traverse (in alr) (alire-solutions.adb:1549)
alire__roots__traverse___wrapped_statements.237 (in alr) (alire-roots.adb:1986)
alire__roots__traverse (in alr) (alire-roots.adb:1966)
alire__builds__hashes__compute (in alr) (alire-builds-hashes.adb:297)
alire__roots__build_hash___wrapped_statements.52 (in alr) (alire-roots.adb:262)
alire__roots__build_hash (in alr) (alire-roots.adb:256)
alire__builds__path__2 (in alr) (alire-builds.adb:102)
alire__roots__release_base___wrapped_statements.181 (in alr) (alire-roots.adb:1455)
alire__roots__release_base (in alr) (alire-roots.adb:1435)
alire__roots__project_paths___wrapped_statements.147 (in alr) (alire-roots.adb:1232)
alire__roots__project_paths (in alr) (alire-roots.adb:1222)
alire__environment__loading__load (in alr) (alire-environment-loading.adb:65)
alire__roots__export_build_environment___wrapped_statements.139 (in alr) (alire-roots.adb:1145)
alire__roots__export_build_environment (in alr) (alire-roots.adb:1142)
alire__roots__build___wrapped_statements.28 (in alr) (alire-roots.adb:230)
alire__roots__build (in alr) (alire-roots.adb:82)
alr__commands__build__execute__2 (in alr) (alr-commands-build.adb:114)
alr__commands__build__execute___wrapped_statements.4 (in alr) (alr-commands-build.adb:91)
alr__commands__build__execute (in alr) (alr-commands-build.adb:51)
alr__commands__sub_cmd__execute (in alr) (clic-subcommand-instance.adb:749)
alr__commands__execute (in alr) (alr-commands.adb:522)
_ada_alr__main (in alr) (alr-main.adb:10)
main (in alr) (b__alr-main.adb:2195)

[mosteo]

Is it that alr isn't treating this compiler crate as a toolchain crate?

It should, from what I see in your index. I will need to dig deeper to see what's going wrong.

[simonjwright]

This seems related:

debug: Visiting now: gnat(/=2020) & (>=11) (indirect,solved)
debug: Status start: gnat_macos_aarch64=13.1.1
debug: sync: process gnat_macos_aarch64=13.1.1
detail: Using default value for configuration 'dependencies.shared': 'TRUE'
debug: Status start: Syncing gnat_macos_aarch64=13.1.1
◷ Syncing build dir... gnat_macos_aarch64=13.1.1... Syncing gnat_macos_aarch64=13.1.1...
stderr: Could not sync build dir from 
/Users/simon/.cache/alire/releases/gnat_macos_aarch64_13.1.1_a8cde682 to 
/Users/simon/.cache/alire/builds/gnat_macos_aarch64_13.1.1_a8cde682_fbd2da445f294a24cf4ee1e225e65c6cc57b6b2e29415fa3f1c1be17ad9ce568
debug: Status ended: Syncing gnat_macos_aarch64=13.1.1             

---

I mentioned above about "several blank lines", it was actually a lot of spaces.

I don’t know what revision of the alire repo I was using, but alr version says

APPLICATION
alr version:               2.0-dev+beta2
libalire version:          2.0-dev+beta2
compilation date:          2023-12-04 09:18:49
compiled with version:     13.1.0

[mosteo]

That new log indeed hints at the crate not being recognized as part of the toolchain. Thanks for the further info.

[simonjwright]

I had gnat_macos_aarch64 in ~/.cache/alire/dependencies; remove it and the problem goes away.

I have (had) several builds of alr around; a mix of pre- and post- the change that made dependencies.shared default to true.

[simonjwright]

alr (at 6768bd) thinks that gnat_macos_aarch64 is a source archive! This doesn't seem to matter if dependencies aren't shared.

I can't see where the source/binary decision is made.

[mosteo]

The source/binary decision is made based on the origin being conditional, yes, it doesn't depend on any explicit attribute in the index manifest.

You were mislead because you used the available field to narrow it down to macOS, but you also need to make the origin conditional on something (even if you use the others ... case to give the value).

Now that you've been bitten by this ( :pray: ), this is likely to be a bit of hidden knowledge that we should make explicit in the docs. Also, at some point, we could add an explicit flag (which we didn't do to avoid breaking compatibility of the index syntax at the time).

[simonjwright]

I tried this, without success:

[origin."case(os)".macos."case(host-arch)".aarch64]
hashes = [
"sha256:24c729b7e40b2fc2d15d3596ed15bbf18f991b592c554a7b5bcbfd4f73f12fd2",
"sha512:5fb3aa48cf39379449abe128bcb157bb3fe3adfc672447134a8692e3fb1ec7bc5ea3552ea9f007da9e51d6c0fa75dad7c042675b5f07bf35082516ea2b026415",
]
url = "https://www.dropbox.com/scl/fi/cntm9v8r2pgds4e20b97p/gnat-macos-aarch64-13.2.1.tar.gz?rlkey=0za63bi833r5pzz7mxqgjjp0b&dl=0"

I also tried an additional line

[origin."case(os)".macos."case(host-arch)"."..."]

... still failed. (I’m not sure if it’s still a source/binary issue, that build’s on another machine. I wish I could use gdb on macOS! I can use lldb, but it doesn’t understand much about Ada at all.)

[simonjwright]

The fix [origin."case(os)".macos."case(host-arch)".aarch64] in my last comment worked just fine after I’d wiped all Alire’s caches, I’m pleased to report!

[mosteo]

Nice. So, to summarize, this should be documented, and there's some breakage with stale caches around.

[mosteo]

error: Alire.Crate_Configuration.Profile_Maps.Constant_Reference: key not in map

This error was directly caused by the compiler not being considered binary. Fixed in #1533.