Hi, alire is failing me again, saying “/home/drm/.local/share/alire/toolchains/gnat_native_14.1.3_965c1e0e/bin/ld: cannot find crtend.o: no file or folder of tish name”
gprbuild/gnatmake work, just not alire.
I tried purging gnat and gprbuild folders and reinstall them, no change.
I’ve already raised a github issue… But if you see somethingo obvious, don’t hesitate to tell me.
details error message
[link] test.adb
/home/drm/.local/share/alire/toolchains/gnat_native_14.1.3_965c1e0e/bin/ld: cannot find crtend.o: Aucun fichier ou dossier de ce nom
collect2: error: ld returned 1 exit status
gprbuild: link of test.adb failed
gprbuild: failed command was: /home/drm/.local/share/alire/toolchains/gnat_native_14.1.3_965c1e0e/bin/gcc test.o b__test.o /home/drm/.local/share/alire/builds/gnatcoll_24.0.0_11c512d1/1972d1797d761d493f1d7fa409cf2d7a7a27429279d468c28e9fabbd97d926f9/lib/gnatcoll/static/libgnatcoll.a /home/drm/.local/share/alire/builds/libgpr_24.0.0_d9c96bda/ab5a8449e50442ee1b11507d1b8b42bcb41f62b0c668a4289f1dc897e911f994/gpr/lib/production/static/libgpr.a /home/drm/.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/schema/lib/static/libxmlada_schema.a /home/drm/.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/dom/lib/static/libxmlada_dom.a /home/drm/.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/sax/lib/static/libxmlada_sax.a /home/drm/.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/input_sources/lib/static/libxmlada_input_sources.a /home/drm/.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/unicode/lib/static/libxmlada_unicode.a -ldl -L/home/drm/test/obj/development/ -L/home/drm/test/obj/development/ -L/home/drm/.local/share/alire/builds/gnatcoll_24.0.0_11c512d1/1972d1797d761d493f1d7fa409cf2d7a7a27429279d468c28e9fabbd97d926f9/lib/gnatcoll/static/ -L/home/drm/.local/share/alire/builds/libgpr_24.0.0_d9c96bda/ab5a8449e50442ee1b11507d1b8b42bcb41f62b0c668a4289f1dc897e911f994/gpr/lib/production/static/ -L/home/drm/.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/unicode/lib/static/ -L/home/drm/.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/sax/lib/static/ -L/home/drm/.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/input_sources/lib/static/ -L/home/drm/.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/dom/lib/static/ -L/home/drm/.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/schema/lib/static/ -L/home/drm/.local/share/alire/toolchains/gnat_native_14.1.3_965c1e0e/lib/gcc/x86_64-pc-linux-gnu/14.1.0/adalib/ -static-libgcc /home/drm/.local/share/alire/toolchains/gnat_native_14.1.3_965c1e0e/lib/gcc/x86_64-pc-linux-gnu/14.1.0/adalib/libgnat.a -ldl -Wl,-rpath-link,/home/drm/.local/share/alire/toolchains/gnat_native_14.1.3_965c1e0e/lib/gcc/x86_64-pc-linux-gnu/14.1.0//adalib -Wl,-z,origin,-rpath,$ORIGIN/…//obj/development:$ORIGIN/…/…//.local/share/alire/builds/gnatcoll_24.0.0_11c512d1/1972d1797d761d493f1d7fa409cf2d7a7a27429279d468c28e9fabbd97d926f9/lib/gnatcoll/static:$ORIGIN/…/…//.local/share/alire/builds/libgpr_24.0.0_d9c96bda/ab5a8449e50442ee1b11507d1b8b42bcb41f62b0c668a4289f1dc897e911f994/gpr/lib/production/static:$ORIGIN/…/…//.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/unicode/lib/static:$ORIGIN/…/…//.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/sax/lib/static:$ORIGIN/…/…//.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/input_sources/lib/static:$ORIGIN/…/…//.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/dom/lib/static:$ORIGIN/…/…//.local/share/alire/builds/xmlada_24.0.0_ae5a015b/491f4fc1c53e9962115b4d147015304630bb0fe17452e174cc1c07e3972f8d1e/schema/lib/static:$ORIGIN/…/…//.local/share/alire/toolchains/gnat_native_14.1.3_965c1e0e/lib/gcc/x86_64-pc-linux-gnu/14.1.0/adalib -o /home/drm/test/bin//test
error: Command [“gprbuild”, “-s”, “-j0”, “-p”, “-P”, “/home/drm/test/test.gpr”] exited with code 4
error: Build failed
Oh and something else unrelated. Is it possible to bundle the ads and adb files together in one ? I mean, and have it recognized by the compiler one way or the other.
I did try a .ada and indeed it complains that there is more than one compilation unit. what a bummer. I just thought maybe there was some command-line option or preprocessing with gnatchop or what not but no. For small projects it can be annoying to always need several files… As Jean Ichibiah said, a smart compiler should be able to tell what has been updated or not. why not just let people manage their project how they want ?
TBH, it’s the legacy of C and UNIX—
Unstructured text is honestly terrible for code:
it forces processing, and re-processing,
this processing doesn’t necessarily need to happen,
but if it’s recorded somewhere and comes out of sync , it blows everything up.
Files are a terrible medium for source:
if there is bookkeeping, then sometimes the bookkeeping info becomes out of sync-
the dependencies upon system attributes (e.g. CASE-INSENSITIVE vs Case-Sensitive)
the dependency on possibly fragile state (e.g. ownership, permissions)
the dependency on locations within the file-system.
IOW, Ichibiah’s “smart compiler” really ought to be one where the source is under far more care and control: say stored as structures in a database — this is to say, an actual integrated-development environment.
Each file contains a single Ada compilation unit, including any pragmas associated with the unit. For example, this means you must place a package declaration (a package spec ) and the corresponding body in separate files. An Ada compilation (which is a sequence of compilation units) is represented using a sequence of files. Similarly, you will place each subunit or child unit in a separate file.
Notice that the example used in 3.3.2 has "myutilst_a.ada" and "myutilst.ada", this is to work around that limitation I spoke of.
Not might, will not be accepted by GNAT: this is an implication of how GNAT implemented Ada83’s “library” feature using the file-system.
Other compilers do not have this limitation.
Did you ever use DEC’s VAX/VMS compiler? It kept an 'Ada Library`, and when it got out of step (not a rare event) you (we) had to wipe the lot and reinsert all the components (as I remember, by hand). I would resist this approach.
You can use gnatname to generate the required pragmas,
pragma Source_File_Name
(List,
Spec_File_Name => "list.ada", Index => 1);
pragma Source_File_Name
(List,
Body_File_Name => "list.ada", Index => 2);
(Index => n means “the nth unit in the file”).
You can get it to generate a .adc file, but I don’t see how to use it (-gnatec=list.adc didn’t work). However, it works fine in a .gpr; see e.g. ACATS-grading/tools.gpr, which I think was created using gnatname though I don’t seem to have a record of the process
DEC Ada had a separate library manager command that the compiler used to store/load objects. Sort of like an interactive linker. The library database was managed in user space on top of the file system.
There’s some documentation here:
I had an account on the Living Computer Museum’s VAX before they shut down. I believe sdf.org inherited that hardware and plans to put it back online. DEC Ada was available on that machine.
Not sure of your point here. All databases are built on a filesystem in somebody’s computer (back in the day Ferranti had/had designed a database engine based on an embedded 68020, AFAICR, but that was/would have been an outlier)
The point is that many systems “bolt on” functionality by “tracking” files within the system, rather than holding the actual-data within the database. The former is prevalent because it’s “easy” and programmers “can use vi/nano/notepad” to edit files. — If you were to have an database which actually contained the data, it would essentially force an IDE to interact with the stored data. (Although I suppose you could have a document database to try to “do both”… but I’ve not heard of that track being taken in any IDE system.)
