You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It looks like I'm having a similar problem to #1160 and #1161.
This problem possibly started after restarting VScode after not quitting for a long time (weeks??).
The Problems panel shows problems with each Ada file, but only when I click on the tab to display the file contents. The problem report for each file remains until I close the file. Also, a problem is reported when my gpr file tab is clicked but using a different theme color to indicate the error.
The problem text for Ada sources, when the tab is clicked, is: The project was loaded, but no Ada runtime found. Please check the installation of the Ada compiler.
The problem for the gpr is reported as can't find a toolchain for the following configuration: language 'Ada', target 'x86_64-darwin', default runtime
I have started logging as suggested in #1160 and the two files created are attached to this post.
Some unordered points:
I am using an ARM M1 Mac, and have done so for several months without this problem.
As far as I know, nothing on my system changed to cause this problem.
I am able to compile and run programs normally.
One of the problem reports, above, complains about target x_86-64-darwin!
Possibly during the extended period that VScode was running, I deleted an old (2015) GNAT for x86-64-darwin which I had not used since getting the M1 Mac.
I have been using the ARM GNAT which lives at /opt/gcc-12.2.0-aarch64.
My Ada-ALS-VScode installation is a little non-standard. My build task is a bash script which, along with other things, calls the gprbuild comnand with my gpr file.
The location of my gpr file is the same as in the VScode preferences for Ada, in the Project File entry.
I keep a symlink at /usr/local/ada which points to /opt/gcc-12.2.0-aarch64.
In my bash .profile file I keep this: export PATH=$PATH:/usr/local/ada/bin.
The above machinery has worked without problems for years.
The syntax checker gnatmake -gnatc bla bla bla works correctly.
MacOS 12.6.5
VScode 1.74.1
ALS 23.0.21
The logs have an empty gpr path.
The logs warn that some dependent gpr files do not contain Ada sources, for example Octave. They aren't suppose to, as the purpose of those gpr files is to direct linking to compiled C code.
When I naively (not that hard) type $ gprbuild without anything else, it reports this: using project file /opt/gcc-12.2.0-aarch64/share/gpr/_default.gpr which is just a placehoder; further, it attempts to compile some little test file from six months ago that I haven't used since.
The text was updated successfully, but these errors were encountered:
Possibly during the extended period that VScode was running, I deleted an old (2015) GNAT for x86-64-darwin which I had not used since getting the M1 Mac.
That probably explains it: you are running an extension built for x86-64-darwin with Rosetta (we don't build it for aarch64 yet), that's why it complains about the missing toolchain.
You may solve this by specifying the Target attribute in your GPR project file, so that it actually targets aarch64.
Thanks. That seems to have fixed it! For reference, the full line in my .gpr file is for Target use "aarch64-darwin";
Glad to hear that! Closing the issue for now. We'll see what we can do to have native support for aarch64-darwin internally though, but no promises here.
It looks like I'm having a similar problem to #1160 and #1161.
This problem possibly started after restarting VScode after not quitting for a long time (weeks??).
The Problems panel shows problems with each Ada file, but only when I click on the tab to display the file contents. The problem report for each file remains until I close the file. Also, a problem is reported when my gpr file tab is clicked but using a different theme color to indicate the error.
The problem text for Ada sources, when the tab is clicked, is:
The project was loaded, but no Ada runtime found. Please check the installation of the Ada compiler.
The problem for the gpr is reported as
can't find a toolchain for the following configuration: language 'Ada', target 'x86_64-darwin', default runtime
I have started logging as suggested in #1160 and the two files created are attached to this post.
Some unordered points:
I am using an ARM M1 Mac, and have done so for several months without this problem.
As far as I know, nothing on my system changed to cause this problem.
I am able to compile and run programs normally.
One of the problem reports, above, complains about target x_86-64-darwin!
Possibly during the extended period that VScode was running, I deleted an old (2015) GNAT for x86-64-darwin which I had not used since getting the M1 Mac.
I have been using the ARM GNAT which lives at /opt/gcc-12.2.0-aarch64.
My Ada-ALS-VScode installation is a little non-standard. My build task is a bash script which, along with other things, calls the gprbuild comnand with my gpr file.
The location of my gpr file is the same as in the VScode preferences for Ada, in the Project File entry.
I keep a symlink at /usr/local/ada which points to /opt/gcc-12.2.0-aarch64.
In my bash .profile file I keep this: export PATH=$PATH:/usr/local/ada/bin.
The above machinery has worked without problems for years.
I am not running Alire.
[als.2023-08-30T195951.93306.log](https://github.com/AdaCore/ada_language_server/files/12482198/als.2023-08-30T195951.9
als.2023-08-30T195951.93307.log
3306.log)
The syntax checker gnatmake -gnatc bla bla bla works correctly.
MacOS 12.6.5
VScode 1.74.1
ALS 23.0.21
The logs have an empty gpr path.
The logs warn that some dependent gpr files do not contain Ada sources, for example Octave. They aren't suppose to, as the purpose of those gpr files is to direct linking to compiled C code.
When I naively (not that hard) type $ gprbuild without anything else, it reports this:
using project file /opt/gcc-12.2.0-aarch64/share/gpr/_default.gpr
which is just a placehoder; further, it attempts to compile some little test file from six months ago that I haven't used since.The text was updated successfully, but these errors were encountered: