Fails to install properly on msys2, GCC 8.2.0

[jere-software]

when running the gprinstall command from the README, I get:

$ gprinstall -f -p -P Winrt_Runtime.gpr Install project Winrt_Runtime gprinstall: error: file does not exist '\winrt_runtime./lib/libother.a'

This is from a fresh pull as of today (5/11/2019) and I followed all the steps as outlined in the readme. GPR file is as follows:

project Winrt_Runtime is

Base_Source_Dir       := Project'Project_Dir;
Base_Installation_Dir := "lib\gcc\x86_64-pc-mingw32\8.2.0/";
Default_Prefix        := Base_Installation_Dir & "rts-Winrt_Runtime";
Install_Prefix        := external ("PREFIX", Default_Prefix);

for Languages use ("Ada", "C", "Asm");
for Library_Auto_Init use "False";
for Library_Name use "gnat";
for Library_Kind use "static";
for Library_Dir use "adalib";
for Object_Dir use "build";
for Source_Dirs use ("adainclude", "cpp");  
for Target use "x86_64-w64-mingw32 ";

type Build_Type is ("Production", "Debug");

Build : Build_Type := external ("BUILD", "Debug");

package Builder is
    for Switches ("Ada") use ("--RTS=" & Project'Project_dir);
end Builder;

package Compiler is
    CFLAGS := ("");

    case Build is
        when "Production" =>
            CFLAGS := CFLAGS & ("-O2");
        when "Debug" =>
            CFLAGS := CFLAGS & ("-O0");
    end case;

    ALL_CFLAGS := ("-fexceptions") & CFLAGS;
    for Switches ("C") use ALL_CFLAGS;

    ALL_ADAFLAGS := ("-g", "-gnatpg", "-nostdinc") & CFLAGS;
    for Switches ("Ada") use ALL_ADAFLAGS;
end Compiler;

package Binder is
end Binder;

package Linker is
end Linker;

package Install is
    for Prefix use Install_Prefix;
    for Required_Artifacts ("") use ("runtime.xml", "ada_source_path", "ada_object_path");
    for Required_Artifacts ("adalib") use ("./lib/libother.a", "./libgnarl/libgnarl.a");
    for Sources_Subdir use "adainclude";
    for Lib_Subdir use "adalib";
    for Install_Project use "false";
end Install;

end Winrt_Runtime;

may be related to this issue: https://github.com/Alex-Gamper/Ada-WinRT-Runtime/issues/1

[Alex-Gamper]

Jere, Their is an intervening step in the build command file ("build.cmd") that creates the libother and libgnarl. Ive updated the readme on GitHub to reflect this step. So if you run the build.cmd rather than running gprbuild/gprinstall directly it will install correctly. Could you confirm

[Alex-Gamper]

Jere, I have also added libother, libgnarl to the repo, just in case

[jere-software]

Alex, sorry for the late reply. Just saw this. For some reason Github didn't alert me that I got a response in my notifications.. I don't have the visual studio command prompt in my copy of VS Community. I'm working on finding out how to add it. For kicks I tried to run build.cmd in my mingw64 shell, but the link commands failed (just trying it to see). Once I get vs command prompt working. I'll answer back.

[jere-software]

So update, I got build.cmd to run correctly in the vs command prompt. I couldn't verify that it installed correctly in my version of GNAT. Where do I look in the GNAT install directory to verify?

[Alex-Gamper]

Hi Jere

The WinRT library will be within the rts-winrt-runtime directory (which follows a similar directory structure to what you are probably familiar with lib, include and share directories). In my env the library is installed to C:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\9.1.1\rts-Winrt_Runtime\lib\winrt

Your GNAT env will be slightly different and should be something along the lines of C:\gnat\2018\lib\gcc\x86_64-pc-mingw32\ ?.?.? \rts-Winrt_Runtime\lib\winrt assuming that your GNAT installation is the default.

Let me know if you have any further issues, glad to help out

Alex

[Alex-Gamper]

Sorry Jere I just realized you are using msys2 8.2 (I thought that you may be using AdaCore professional, Its a late Sunday here in Sydney, and I've had a glass of wine :-) . So the winrt libraries in your case should have been installed to C:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\8.2.1\rts-Winrt_Runtime\lib\winrt if you installed to the default msys2 directory (otherwise just replace the c:\msys64 with your install dir

If you run gnatls as shown below, it will advise you of the directory structure

c:>gnatls -v --RTS=winrt_runtime

GNATLS 9.1.1 20190504 [ibm/gcc-9-branch revision 270862] Copyright (C) 1997-2019, Free Software Foundation, Inc.

Source Search Path:

C:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\9.1.1\rts-winrt_runtime\adainclude Object Search Path: C:\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\9.1.1\rts-winrt_runtime\adalib Project Search Path: C:\msys64\mingw64\x86_64-w64-mingw32\winrt_runtime\lib\gnat C:\msys64\mingw64\x86_64-w64-mingw32\winrt_runtime\share\gpr C:\msys64\mingw64\x86_64-w64-mingw32\lib\gnat C:\msys64\mingw64\x86_64-w64-mingw32\share\gpr C:\msys64\mingw64\share\gpr C:\msys64\mingw64\lib\gnat

[jere-software]

Oddly, it didn't install it into my 8.20 mingw64 path. Instead it created a 8.2.0 directory in my GNAT CE install path instead. I did set the path to point to my mingw64 version first. I wonder what caused it to go to the wrong place. I'm not very well versed in the visual studio command prompt, so I must have done something wrong. Any suggestions? Do I need to set some configuration parameter maybe?

[jere-software]

For reference, I open up the VS command prompt and do:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community>set PATH=D:\Program_Files\msys64\mingw64\bin;%PATH%

I then verify the path shows up by echoing the PATH variable.

I run Build.CMD but it installs it to my GNAT CE directory instead. Odd

[jere-software]

Maybe I can just cut and paste the runtime to the right location? I don't know if there are any other hooks for runtimes in GNAT though.

[Alex-Gamper]

Hi Jere It might be that you don't have gprbuild/gprinstall installed on msys2, and because the install path in the gpr file is a relative one, it installs under the GNAT CE ??. (which is where I suspect gprbuild/gprinstall is located) You can do either of the following

a) Set the Base_Installation variable in the winrt-runtime.gpr file to an absolute path ie D:\Program_files\msys64\mingw64\lib\gcc... rather than just lib\gcc..

b) Simply copy the rts_runtime directory to the appropriate place, this is fairly safe and Ive done this in the past without issues

Note your path statements look fine, but I would recommendd to build/install GRPBUILD in msys2, the procedure is fairly straight forward and well documented on the AdaCore GitHub repo located here. If you dont then we may find issues with building winrt.gpr ???

https://github.com/AdaCore/gprbuild

Just do the bootstrap procedure, I've never really had to more than that, Let me know how you go

Alex

[Alex-Gamper]

Hi Jere

If you do decide to build GPRBUILD for msys2, I would advise to remove the GNAT CE from your path before doing so (just as a precautionary measure to mitigate you possably poluting your GNAT CE environment)

Alex

[Alex-Gamper]

Hi Jere

I just noticed you winrt-runtime.gpr also has a issue ? (You may have already changed it, For Msys2 it should be lib\gcc\x86_64-w64-mingw32\8.2.0/ ??? you have -pc- above

The triplet for msys2 is usually x86_64-w64-mingw32 The triplet for gnat CE is usually x86_64-pc-mingw32

If you do a gcc -v the --target= parameter will tell you what your triplet is (as well as other things) But you knew that :-)

Alex

[jere-software]

Hi Jere It might be that you don't have gprbuild/gprinstall installed on msys2, and because the install path in the gpr file is a relative one, it installs under the GNAT CE ??. (which is where I suspect gprbuild/gprinstall is located) You can do either of the following

a) Set the Base_Installation variable in the winrt-runtime.gpr file to an absolute path ie D:\Program_files\msys64\mingw64\lib\gcc... rather than just lib\gcc..

b) Simply copy the rts_runtime directory to the appropriate place, this is fairly safe and Ive done this in the past without issues

I did (a) and it seemed to install correctly as far as I can tell.

Note your path statements look fine, but I would recommendd to build/install GRPBUILD in msys2, the procedure is fairly straight forward and well documented on the AdaCore GitHub repo located here. If you dont then we may find issues with building winrt.gpr ???

https://github.com/AdaCore/gprbuild

Just do the bootstrap procedure, I've never really had to more than that, Let me know how you go

Alex

I've never been able to get a successfully built gprbuild out of their procedure. It always builds, but running gprbuild fails out with an exception. I haven't tried in about 2 years though, so maybe it is better. I was able to get the build script to work by changing the directory to an absolute path.

Thanks!

[jere-software]

Hi Jere

If you do decide to build GPRBUILD for msys2, I would advise to remove the GNAT CE from your path before doing so (just as a precautionary measure to mitigate you possably poluting your GNAT CE environment)

Alex

When I did try and build it, GNAT CE isn't in the build path. My general setup for mingw64 doesn't know the GNAT CE version exists. Command Prompt, VS Command Prompt, and Power Shell all know the GNAT CE version exists but don't know about the mingw64 version.

[jere-software]

Hi Jere

I just noticed you winrt-runtime.gpr also has a issue ? (You may have already changed it, For Msys2 it should be lib\gcc\x8664-w64-mingw32\8.2.0/ ??? you have -pc-_ above

The triplet for msys2 is usually x86_64-w64-mingw32 The triplet for gnat CE is usually x86_64-pc-mingw32

If you do a gcc -v the --target= parameter will tell you what your triplet is (as well as other things) But you knew that :-)

Alex

Good Catch. I think when I repulled the repo it fixed it the second time. I still needed the absolute path to get it to work, but at least I got it to install. No manifest was installed to share/gpr/manifests, but that may not happen for runtimes (not really sure). I think for now I am good until I run into another problem. Should I close this or hold off?

[Alex-Gamper]

Hi Jere Good to see that you got it built and installed correctly. Lets leave it open for now, so that others can see some of the things to watch out for. Also just a few points on the above.

1) I built/installed gprbuild a few times over the last few months and only really had issues with a 32bit build. mingw64 works fine from a clean environment (ie one without gprbuild) and doing a bootstrap, and then going back to build xmlada and then gprbuild proper. But I usually just do the bootstrap.

2) Path's can be problematic on powershell, cmd prompt or VS command prompt's as you can easily get into a situation where you end up using parts of GNAT CE and parts of Mingw64, something to avoid if possible.

3) Yes, their will not be a manifest installed for the runtime, I dont know why ? But you can easily re-install by deleting the rts-winrt_runtime directory, which is fairly safe to do since RTS's are by design isolated and self contained so to speak.

Alex

[jere-software]

In that case, a side / related question. Let me know if I should open a separate issue or not for this:

So far through all of of this, the only thing I have actually needed the VS Command Prompt for is the link commands. I've so far done winrt_runtime and winrt, but haven't tried the actual vs ada extension yet. Do you know of any way to emulate the link commands in an msys bash shell? Calling them as is didn't work due to some command differences. The reason I ask is because, at work, they disable the command prompt application, which I think the VS command prompt is built on. msys2 bash shell works fine however. I haven't yet tried to do it in powershell and they plan on removing it in the future at work.

If the ada vs extension requires the vs command prompt, this may be moot, but just being proactive here and at least asking you on the off chance I can find a way to get it to work.

[Alex-Gamper]

Hi Jere

The Ada vs extension does not explicitly need the vs command prompt. It does however use facilities and api's similar to fork/shell/exec unix/Linux equivalents to determine where gcc is installer, and where the source/lib and project files are via invoking gnatls. None of this requires admin/elevated privs and does not execute cmd.exe, but the underlying where.exe, gnatls.exe etc... So in summary I think you are fine !

I'll setup a VisualAda GitHub repo soon, so you can raise issues their, But in the meantime feel free to ask here

Alex

[Alex-Gamper]

Hi Jere

Note that Visual Studio and any installed extensions don't require a VS command shell as such, since VS utilizes the underlying MSBUILD engine (which knows or can figure out where the build toolchain is. So if your company allows you to build C/C++ via Visual Studio, then their should not be any reason why VisualAda should not work in your environment (technical issues within VisualAda aside)

Going forward, I intend to provide NUGET packages for both the winrt-runtime and winrt, which will alleviate the need to build/install both libraries

Does your company have polocies on the use of NUGET ?

Alex

[jere-software]

Hi Jere

Note that Visual Studio and any installed extensions don't require a VS command shell as such, since VS utilizes the underlying MSBUILD engine (which knows or can figure out where the build toolchain is. So if your company allows you to build C/C++ via Visual Studio, then their should not be any reason why VisualAda should not work in your environment (technical issues within VisualAda aside)

I think the only thing that requires the VS command prompt so far is building the winrt runtime, at least until I can figure out how to get a working LINK commmand. I've explicitly called the link.exe from visual studio, but there are some pathing errors I have to figure out next as it cannot find the right libs. I am guessing the the VS command prompt has something in its path that I am missing.

Going forward, I intend to provide NUGET packages for both the winrt-runtime and winrt, which will alleviate the need to build/install both libraries

Does your company have polocies on the use of NUGET ?

Alex

So that is a fun question. The windows command prompt is outright restricted so it cannot be used. For external programs it is on a case by case basis. Visual Studio is allowed and, by proxy, any programs packaged with it. So if NUGET comes with Visual Studio, then I should be fine (see note at the end). If NUGET is a separate application, then I need to do some research and see what I can figure out.

Note, that even if it is allowed, it still my have troubles running due to our security software. I'm having that exact trouble with the Rust compiler right now. It's approved to be installed, but the security software is making installation challenging.

[Alex-Gamper]

Hi Jere

Have you tried running the Microsoft Link Command from within a bash shell ? I've just setup my PATH as below (please note the '\' character, used as an escape sequence in a bash shell

export PATH=/c/Program\ Files\ (x86)/Microsoft\ Visual\ Studio/2019/Professional/VC/Tools/MSVC/14.21.27702/bin/Hostx64/x64:$PATH

The link command does then work from a BASH shell. Note the /c/ which refers to C:\ drive, and you may need to adjust the other directory names. I haven't yet done a full link as per the winrt-runtime script but it should work

Alex

[jere-software]

Yep, I already had tried that. The link command fails with:

LINK : fatal error LNK1181: cannot open input file msys2_baseinstall_directory/lib.obj

Even though I am not calling the command from that location. So I think there is something else I need in the path for the link command to work. It definitely calls the correct MS link command (There are some print statements above that that indicate it is correct).

I did note, that the README.md file has the wrong command syntax. It ends with ./lib.o instead of ./lib/.o guessing a markdown issue?