How to run an executable build by alire?

[pjljvandelaar]

Dear Alire developers,

I had expected to be able to run an executable build by alire without using alire.
Maybe this is a misconception at my side,
since e.g. running gnatpp from the libadalang_tools crate only works
correctly via alire:

PS C:\path\to\libadalang_tools_22.0.0_c9028428> .\bin\gnatpp.exe --version
PS C:\path\to\libadalang_tools_22.0.0_c9028428> alr run gnatpp.exe --args="--version"
gnatcoll.gpr:254:07: warning: value "windows" is not used as label
gnatcoll.gpr:254:07: warning: value "windows" is not used as label
gprbuild: "gnatpp.exe" up to date
gprbuild: "gnatmetric.exe" up to date
gprbuild: "gnatstub.exe" up to date
gprbuild: "gnattest.exe" up to date
gprbuild: "utils-var_length_ints-test.exe" up to date
GNATPP Pro dev
Copyright (C) 2004-unknown, AdaCore.
This is free software; see the source for copying conditions.
See your AdaCore support agreement for details of warranty and support.
If you do not have a current support agreement, then there is absolutely
no warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Is this indeed the intended behaviour?
If so, can you please explain why alr should always be involved - not just in the build/compile phase?
If not, what have I done wrong? The gnatpp.exe file is present...

Greetings,
Pierre

[mosteo]

Is the first run not producing any output at all?

I guess this might happen when there are dynamically linked libraries involved. It's one of the reasons behind #948

[mosteo]

If this were Linux, I would say to run ldd on your executable to see which dynamic libraries are been looked for. Alas, I don't know the Windows equivalent.

[pjljvandelaar]

running alr edit
shows that the default is indeed static:

I am searching for the windows equivalent of ldd...

[pjljvandelaar]

Turns out git bash supports ldd

I get

laarpjljvd@PC-17716 MINGW64 /c/path/to/Dependency_Graph_Extractor-Ada (main)
$ ldd bin/dependency_graph_extractor.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd1c190000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffd1bfd0000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffd198b0000)
        ADVAPI32.dll => /c/WINDOWS/System32/ADVAPI32.dll (0x7ffd1a940000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffd1b7d0000)
        sechost.dll => /c/WINDOWS/System32/sechost.dll (0x7ffd1b0e0000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ffd1b9b0000)
        libiconv-2.dll => /mingw64/bin/libiconv-2.dll (0x7ffce3040000)
        PSAPI.DLL => /c/WINDOWS/System32/PSAPI.DLL (0x7ffd1b260000)
        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ffd1af30000)
        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ffd19e90000)
        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ffd1c110000)
        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ffd19b80000)
        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ffd19df0000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffd19ef0000)
        libgmp-10.dll => /mingw64/bin/libgmp-10.dll (0x7ffcf2e00000)

I don't see libadalang, so that surprises me.
Further, I have no experience with ldd so I don't know whether this is good or wrong ;-(

[Fabien-Chouteau]

Looks like libadalang is statically linked but not libgmp:

libgmp-10.dll => /mingw64/bin/libgmp-10.dll (0x7ffcf2e00000)

Can you try to run the executable from an msys2 shell?

[mosteo]

That's expected, and it means that it is indeed linked in statically. And all dynamic libraries have path and address, which means they're properly found.

Which in turn means that the problem is different in nature, I'd say. What happens when running dependency_graph_extractor.exe directly?

EDIT: good catch by Fabien.