Notes on building libadalang_tools with alire

First and foremost, this is not an alire issue. On the contrary, I am really impressed how alire did the job!

I am using msys2/mingw64 on Win10, 16GB RAM. I used alire to download libadalang_tools (and dependencies). I run alr from a mingw64 tty. (not a PowerShell fan.)

After about 10x “alr build” on the downloaded crate it finally succeeded in building the tools. All but the last “alr build” resulted in out-of-memory errors. But since “alr build” (or rather gprbuild) picks up where it crashed the last times I gradually progressed to a successful completion. Questions:

  1. Is this a known phenomenon?
  2. according to the alr build output at each memory allocation crash it used a “-j0” flag to grpbuild. Now it can’t use 0 sub-processes to build but I didn’t expected to see 4 active gnat1 processes. I guess that using only 1 sub-process could alleviate the memory allocation issues. Did somebody encounter the same problems and found a solution?
  3. Gnattest is one of the tools build. In the gnattest documentation some examples are discussed, they are supposed to be in the share subfolder. There are no examples (in this crate). Or are these exclusive for GNAT Pro users? If not where could I get them?
  4. When running gnattest from GNAT Studio (26.0w) (Analyze->GNATtest->Generate Unit Test Setup) a dialog is shown to set additional switches. Default a “-dd” switch is present. What does “-dd” do? It is not documented … ? “$ gnattest –help” shows no “-dd” flag, gnattest itself considers “-dd” a valid flag. Anybody thoughts on this?

Regards, Rob

1 Like

I had the same problem with compilation of libadalang. The shell crashed. I’m on old MacBook Air hardware installed with Debian 12. 4 GB of RAM. `alr build – -j1` solved the problem. I also added some more swap. `-j0` uses double the number of cores I think.

Perhaps it means double -d ..