[ANN] aDSA 1.3.0 — ZeroMQ-backed Annex E (DSA) runtime for GNAT — now runs on Windows and FreeBSD

charlie5 · July 7, 2026, 1:14am

aDSA is a free (GPLv3 + GCC Runtime Library Exception) Partition
Communication Subsystem for Ada’s Distributed Systems Annex (Annex E),
built on ZeroMQ — a runtime replacement for the deprecated PolyORB /
GLADE. The compiler side of Annex E is alive and well in FSF GNAT; aDSA
supplies the other half: System.RPC / System.Partition_Interface
implementations the generated stubs call into, plus pcs_gnatdist, a
gnatdist-style build tool that takes the classic .cfg configuration
language and produces the partition executables and a launcher.

It covers the full annex — RCI, RACW/RAS (including callbacks),
Shared_Passive (three backends: file, a cross-host store server, and
same-host shared memory), asynchronous calls, termination policies,
restart recovery, and the RM E.3 version check — plus opt-ins for zlib
compression, XDR wire format, and CurveZMQ encryption with per-partition
peer authentication. It is validated against the original PolyORB
examples/dsa corpus.

New in 1.3.0 — the platform release:

Windows 11: full bring-up with the Alire toolchain (gnat_native
15.2.1 + gprbuild 26.0.1, Alire’s bundled MSYS2 bash). The verification
corpus passes 6/6 on both build paths — the same scoreboard as Linux —
and all three Shared_Passive backends run, including shared memory.
FreeBSD 15.1: corpus plus the full feature sweep (XDR, peer-auth,
and a real two-machine cross-host deployment).
pcs_gnatdist now lints RCI specs against the RM E.2.3 legality rules
up front, instead of letting violations surface as puzzling linker
errors.
Assorted fixes — details in the changelog.

Linux remains the primary platform (Arch users get a PKGBUILD whose
pacman hook rebuilds the runtime automatically on every gcc-ada
upgrade).

Repo

Release

User’s Guide

One known FSF GNAT limitation worth mentioning: dispatching to an RACW
of a Remote_Types interface can pick the wrong slot when the concrete
type declares its own primitives before its overrides (filed as PR
ada/126014, reproducer included in the repo). The documented workaround
is to route such calls through a concrete RCI.

There is also a sibling project, ipDSA
( charlie5/ipDSA: An Ada DSA implementation using Kazakov simple component inter-process streams and sockets for comms. - Codeberg.org ), which is the same PCS with the
transport swapped for shared-memory interprocess streams — for
same-host-only deployments with no network stack involved. The two
Arch packages co-install cleanly.

Feedback, bug reports, and testing on other platforms are very welcome.

joakim-strandberg · July 20, 2026, 8:23pm

Hi Charlie5,

Nice work on making PolyORB ZeroMQ backed.

Some questions:

Is there a recommended way to detect if a partition has already started? So it is possible to gracefully shutdown a partition if it is already started.
I also wonder about encryption. I looked for an example where peer authentication on partitions is enabled but could not see an example in the examples/ directory. Or am I mistaken? In the documentation it says " DSA_AUTH=peer + DSA_NS_CURVE_*", how should one interpret DSA_NS_CURVE_* ? Should each partition have its own DSA_NS_CURVE_<partition_name> or how should one use the DSA_NS_CURVE_* environment variables?

Best regards,
Joakim

charlie5 · July 21, 2026, 8:31am

Hi Joakim,

Thanks — both of these were genuinely underdocumented, and you prompted me to
fix them, so this reply also comes with runnable code and clearer docs on the
main branch.

Encryption / DSA_NS_CURVE_*. You read the notation the reasonable way, and
it was ambiguous — sorry. The * is just shorthand for the two suffixes
SECRET and PUBLIC; it is not a per-partition placeholder. There is
no DSA_NS_CURVE_<partition>, and you never configure a key per partition by
hand.

There are two separate models:

Shared system key (DSA_CURVE_SECRET / DSA_CURVE_PUBLIC): a single
keypair for the whole deployment — secret on binders, public on connectors;
in practice set both on every process. Encrypts all traffic, but any holder
of the pair is trusted. Generate with eval "$(pcs_keygen)".
Per-partition mutual authentication (DSA_AUTH=peer): here
DSA_NS_CURVE_SECRET/DSA_NS_CURVE_PUBLIC is the infrastructure keypair —
one pair for the entire deployment, generated with pcs_keygen ns.
Distribute it like this:
- DSA_NS_CURVE_SECRET → the name server (and pcs_dsm, if used) only;
  it becomes the trust anchor.
- DSA_NS_CURVE_PUBLIC → every process (all partitions and the name
  server), which pin the name server’s key.
- DSA_AUTH=peer → every process as well.
- Each partition generates its own keypair automatically at startup —
  nothing to configure. It registers its public key with the name server, and
  partitions authenticate one another by asking the name server whether a
  presented key is a registered partition’s (a ZAP handler + an internal
  KEYOK check). An unregistered identity is rejected at the handshake.
On one host you can eval "$(pcs_keygen ns)" once and launch everything from
that shell (each process reads only what it needs). Across hosts: secret only
on the name-server host, public everywhere.

You were also right that there was no runnable peer-auth example — only
rogue.adb. There’s now a complete one: examples/peer-auth/
(run_peer_auth.sh) — it sets up the infra key, runs a legitimate registered
client that succeeds, then fires the rogue with a fresh unregistered identity,
which is denied at the ZAP handshake. The DSA_NS_CURVE_* explanation above is
now written up in docs/users-guide.md §9 (“Encryption in practice”). Both
are on main.

Detecting an already-started partition. There’s no turnkey “singleton /
refuse-second-instance” feature today, but the pieces are there:

Detection: the name server is the registry — every partition registers
its units on startup. So “is a partition hosting unit X already up?” is
answerable by resolving X. From Ada,
System.Partition_Interface.Get_Active_Partition_ID ("X") returns the hosting
partition’s id if one is running, and raises Communication_Error if not —
you can call that in your main before handing off to Run.
What happens if you start a second instance today: both register; the name
server’s unit→partition mapping is latest-wins, so the new instance
transparently takes over and callers re-resolve to it (the restart-recovery
path). It does not error or refuse.
Gracefully shutting the existing one down: the mechanism exists — the name
server sends a one-byte 'X' shutdown frame to a partition’s control endpoint
(that’s how global termination and the liveness watchdog stop partitions) —
but it isn’t yet exposed as a targeted “shut down partition N” command. A small
name-server verb, or a one-line client that resolves the unit and sends 'X'
to its control endpoint, would give exactly the “gracefully replace the
already-started instance” behaviour you want.

This “detect and replace” pattern is really the job of a supervisor/orchestration
layer on top of the PCS, which I’ve just sketched as a design entry — see
docs/developers-guide.md §16. Happy to go deeper on any of it.

Regards.

joakim-strandberg · July 21, 2026, 8:24pm

Thanks charlie5 for the clarifications and detailed explanations!

Best regards,
Joakim

DrPi · July 22, 2026, 9:32pm

Is it possible to use it with a process running on a PC (Windows or Linux) on one side and a process running on a ARM device (Linux) on the other side ?

charlie5 · July 23, 2026, 12:47am

A good question and the answer should be yes.

The DSA_XDR=1 build flag should take care of any endian difference, as well as any type size differences (such as is possible with Long_Integer).

I have not tested for ARM, as yet, but will do so today and let you know the results.

I have run a test with 3 partitions across separate Windows, freeBSD and Linux VM’s successfully. The freeBSD box even used an older GCC/GNAT (v15) than on the other two (v16).

Anyways, will test ARM now.

charlie5 · July 23, 2026, 7:04am

Just tested on ARM with Debian 13 and GCC/GNAT v14. All tests ran successfully, except that I was mistaken about XDR handling type size differences (such as Long_Integer). These aren’t handled by XDR but a warning is now given by gnatdist when such types are used.

dmitry-kazakov · July 23, 2026, 7:27am

Which one? Debian supports both armhf (32-bit ARM) and aarch64 (64-bit ARM).

charlie5 · July 23, 2026, 7:37am

armhf

armv7l, machine virt-11.0, cortex-a15, 4 vCPUs, 3 GB RAM

The other partition was running under arch linux on an amd64 box.

DrPi · July 23, 2026, 3:35pm

Interesting. Thanks.

Maybe I’ll use it in a future project at work if Ada is used, which is not sure at all

DrPi_Work · August 5, 2026, 7:53am

I’d like to create a demo based on the examples of aDSA to learn how it works and to show to my colleagues.

Is there a detailed documentation about compiling on Windows 11 ?
I use Alire 2.1.1.

I had quite hard time to run build_gnatdist.sh successfully (in Alire prompt).
adsa/build/gnatdist-obj folder and pcs_gnatdist.exe have been built.

Running build_echo_gpr.sh in a Alire prompt fails with :

bash: cd: /z/ada/adsa/examples/echo/../../build/garlic-rts: No such file or directory

Edit :

I run build_rts.sh as it is not run automatically.

system adainclude : C:/Users/nicolas/AppData/Local/alire/cache/toolchains/gnat_native_16.1.0_bbd69633/bin/../lib/gcc/x86_64-w64-mingw32/16.1.0/adainclude
system adalib     : C:/Users/nicolas/AppData/Local/alire/cache/toolchains/gnat_native_16.1.0_bbd69633/bin/../lib/gcc/x86_64-w64-mingw32/16.1.0/adalib
kazakov sources   : /z/ada/adsa/third_party/simple_components (os-windows)
custom RTS        : /z/ada/adsa/build/garlic-rts
  compiling strings_edit
  compiling strings_edit-fields
  compiling strings_edit-integer_edit
  compiling strings_edit-integers
  compiling strings_edit-quoted
  compiling synchronization
  compiling synchronization-windows
  compiling synchronization-interprocess
synchronization-interprocess.ads:381:13: warning: intrinsic binding type mismatch on parameter 2 [enabled by default]
synchronization-interprocess.ads:381:13: warning: profile of "Compare_And_Swap" doesn't match the builtin it binds [enabled by default]
  compiling synchronization-interprocess-mutexes
  compiling synchronization-interprocess-generic_shared_object
  compiling system_errno
  compiling pcs_config
  compiling pcs_zmq
  compiling pcs_zlib
  compiling pcs_transport
  compiling s-rpc
  compiling s-parint
s-parint.adb:428:56: warning: aspect Unreferenced specified for "Version" [enabled by default]
s-parint.adb:479:07: warning: use clause for type "Interfaces.Unsigned_64" has no effect [-gnatwu]
s-parint.adb:480:07: warning: use clause for type "System.Address" has no effect [-gnatwu]
  compiling s-shasto
  compiling s-dsaser
GARLIC RTS ready: /z/ada/adsa/build/garlic-rts

I’ve copied libz.a, libz.dll.a, libzmq.a and libzmq.dll.a from MSYS2 to compiler location manually.

Running build_echo.sh generates object files but fails on link.

== building server_main.adb into obj-server (-gnatzr) ==
C:/Users/nicolas/AppData/Local/alire/cache/toolchains/gnat_native_16.1.0_bbd69633/bin/../lib/gcc/x86_64-w64-mingw32/16.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: Z:/ada/adsa/build/garlic-rts\adalib\s-parint.o:s-parint.adb:(.rdata$.refptr.__executable_start[.refptr.__executable_start]+0x0): undefined reference to `__executable_start'
collect2.exe: error: ld returned 1 exit status
gnatlink: error when calling C:\Users\nicolas\AppData\Local\alire\cache\toolchains\gnat_native_16.1.0_bbd69633\bin\gcc.exe

Running build_echo_gpr.sh fails too.

Note : I have to manually add compiler and gpr paths in Alire prompt to be able to compile.

charlie5 · August 6, 2026, 8:37am

Hi DrPi,

Good news: nothing is broken — you just entered through a door that wasn’t the
entrance. Your report was genuinely useful, too: it led to several fixes that
are now released in v1.5.0, so the path you tried works out of the box.

What happened

examples/echo/build_echo_gpr.sh (and its sibling build_echo.sh) are
historical hand-driven scripts, kept as reference material documenting what
pcs_gnatdist automates. They expect the custom GARLIC runtime to already
exist at build/garlic-rts — and nothing you had run builds it
(build_gnatdist.sh deliberately uses the stock runtime). Hence the bare
cd: ... No such file or directory.

Since v1.5.0, thanks to your report:

all the hand-driven example scripts print a friendly explanation (with the
two ways to fix it) instead of that bare error, and
the echo example’s hand-written project files gained a Windows-specific
link fix (Linker'Trailing_Switches) — that would have been the next
error you hit. Both build paths of the echo example are now verified on
Windows 11.

The supported path

From Alire’s MSYS2 bash prompt (as you were), after updating to v1.5.0:

alr build       # the repo is now an Alire workspace
                # (equivalent: bash scripts/build_gnatdist.sh)
build/pcs_gnatdist examples/gd-echo/gd-echo.cfg
bash examples/gd-echo/run_gd.sh          # -> result = 42, clean shutdown

pcs_gnatdist auto-builds the custom runtime (and the name server) on first
use — and since v1.5.0 it also rebuilds it automatically if you ever switch
Alire toolchains. (alr install --prefix=<dir> works too, if you prefer the
tools on your PATH.) If you still want the hand-driven echo scripts
afterwards — they are a nice way to show what the tool automates — run
bash scripts/build_rts.sh first.

Going one step further: aDSA v1.5.0 has been submitted to the Alire
community index (alire-index#2050,
checks green, awaiting review). Once it merges, no manual clone is needed at
all: alr install adsa is the simplest way to get the tools — it puts
pcs_gnatdist on your PATH (with the full tree, examples included, under
the prefix’s share/adsa) — while alr get adsa fetches a browsable
workspace right where you are, which is handy for exploring and adapting
the examples with your colleagues.

Windows 11 documentation

The README’s Platforms → Windows section has the one-time setup, and §2 of
docs/users-guide.md the general flow. Short version (verified with Alire
gnat_native 15.2.1 + gprbuild 26.0.1 on Windows 11):

from an MSYS2 shell: pacman -S mingw-w64-x86_64-zeromq mingw-w64-x86_64-zlib
copy libzmq.dll.a and libz.a from mingw64/lib into your Alire
toolchain’s x86_64-w64-mingw32/lib/ — the Alire GNAT doesn’t search
/mingw64/lib, and the runtime build needs both
keep mingw64/bin on PATH at runtime, so the DLLs are found
drive everything from Alire’s MSYS2 bash (as you already do) — the
scripts and generated launchers are bash, not PowerShell

If the first pcs_gnatdist run fails around libzmq, it’s almost certainly
step 2. You can validate the whole setup with bash scripts/verify_fork.sh —
on Windows it scores 6/6 on both build paths (the dsa-json -P variant
additionally needs GNATCOLL installed).

For the demo to your colleagues

gd-echo is the minimal one; dsa-bank and dsa-mailboxes (from the
original PolyORB corpus) are realistic multi-partition apps; racw-callback
and concurrent show distributed callbacks and the server-side worker pool.
The users-guide walks through writing your own distributed application from
scratch — probably the best colleague-facing document.

Thanks again for the report — you’re the first outside user to exercise the
Windows path, and v1.5.0 is better for it.

DrPi_Work · August 7, 2026, 1:27pm

Hi @charlie5 ,

Thanks for your answer.

Sorry to say that but it still does not compile on my machine.

Running alr build in a Alire prompt (powershell) is OK.

Running build/pcs_gnatdist examples/gd-echo/gd-echo.cfg fails :

PS Z:\ada\adsa> build/pcs_gnatdist examples/gd-echo/gd-echo.cfg
[pcs_gnatdist] building the name server / DSM / keygen ...
<3>WSL (10 - Relay) ERROR: CreateProcessCommon:640: execvpe(/bin/bash) failed: No such file or directory
runtime setup failed: command failed: bash Z:\ada\adsa/scripts/build_nameserver.sh

WSL interfere.

I’m not sure I run it in the correct prompt. When you say From Alire’s MSYS2 bash prompt, does it means a Alire’s prompt (powershell) or a MSYS2 prompt (MSYS2 installed by Alire) ?

I tried from a MSYS2 (Alire’s one) prompt but the compiler is not found, which is not surprising. I tried to add the compiler and gprbuild paths but this is not enough. There are still missing things but I guess this is not the way to go.

Edit :

To go further, I tried to run the command through Alire with alr exec -- build/pcs_gnatdist examples/gd-echo/gd-echo.cfg :

[pcs_gnatdist] building the PCS runtime (RTS) -- one-time / after src/pcs or toolchain changes ...
system adainclude : C:/Users/nicolas/AppData/Local/alire/cache/toolchains/gnat_native_15.2.1_346e2e00/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/adainclude
system adalib     : C:/Users/nicolas/AppData/Local/alire/cache/toolchains/gnat_native_15.2.1_346e2e00/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/adalib
kazakov sources   : /z/ada/adsa/third_party/simple_components (os-windows)
custom RTS        : /z/ada/adsa/build/garlic-rts
  compiling strings_edit
  compiling strings_edit-fields
  compiling strings_edit-integer_edit
  compiling strings_edit-integers
  compiling strings_edit-quoted
  compiling synchronization
  compiling synchronization-windows
  compiling synchronization-interprocess
synchronization-interprocess.ads:381:13: warning: intrinsic binding type mismatch on parameter 2 [enabled by default]
synchronization-interprocess.ads:381:13: warning: profile of "Compare_And_Swap" doesn't match the builtin it binds [enabled by default]
  compiling synchronization-interprocess-mutexes
  compiling synchronization-interprocess-generic_shared_object
  compiling system_errno
  compiling pcs_config
  compiling pcs_zmq
  compiling pcs_zlib
  compiling pcs_transport
  compiling s-rpc
  compiling s-parint
s-parint.adb:4:06: warning: redundant with clause in body [-gnatwr]
s-parint.adb:7:06: warning: redundant with clause in body [-gnatwr]
s-parint.adb:8:06: warning: redundant with clause in body [-gnatwr]
s-parint.adb:444:56: warning: aspect Unreferenced specified for "Version" [enabled by default]
s-parint.adb:494:07: warning: use clause for type "System.Address" has no effect [-gnatwu]
s-parint.adb:494:07: warning: use clause for type "Interfaces.Unsigned_64" has no effect [-gnatwu]
  compiling s-shasto
  compiling s-dsaser
GARLIC RTS ready: /z/ada/adsa/build/garlic-rts
[pcs_gnatdist] building the name server / DSM / keygen ...
gcc -c -IZ:/ada/adsa/src/nameserver/ --RTS=Z:/ada/adsa/build/garlic-rts -I/z/ada/adsa/src/nameserver -fPIC -g -I- -o Z:\ada\adsa\build\nameserver-obj\pcs_nameserver.o Z:/ada/adsa/src/nameserver/pcs_nameserver.adb
gnatbind --RTS=Z:/ada/adsa/build/garlic-rts -aI/z/ada/adsa/src/nameserver -aOZ:\ada\adsa\build\nameserver-obj -x Z:\ada\adsa\build\nameserver-obj\pcs_nameserver.ali
gnatlink Z:\ada\adsa\build\nameserver-obj\pcs_nameserver.ali -fPIC -g -o Z:/ada/adsa/build/pcs_nameserver.exe -lzmq
built: /z/ada/adsa/build/pcs_nameserver
gcc -c -IZ:/ada/adsa/src/nameserver/ --RTS=Z:/ada/adsa/build/garlic-rts -I/z/ada/adsa/src/nameserver -fPIC -g -I- -o Z:\ada\adsa\build\nameserver-obj\pcs_dsm.o Z:/ada/adsa/src/nameserver/pcs_dsm.adb
gnatbind --RTS=Z:/ada/adsa/build/garlic-rts -aI/z/ada/adsa/src/nameserver -aOZ:\ada\adsa\build\nameserver-obj -x Z:\ada\adsa\build\nameserver-obj\pcs_dsm.ali
gnatlink Z:\ada\adsa\build\nameserver-obj\pcs_dsm.ali -fPIC -g -o Z:/ada/adsa/build/pcs_dsm.exe -lzmq
built: /z/ada/adsa/build/pcs_dsm
gcc -c -IZ:/ada/adsa/src/nameserver/ --RTS=Z:/ada/adsa/build/garlic-rts -I/z/ada/adsa/src/nameserver -fPIC -g -I- -o Z:\ada\adsa\build\nameserver-obj\pcs_keygen.o Z:/ada/adsa/src/nameserver/pcs_keygen.adb
gnatbind --RTS=Z:/ada/adsa/build/garlic-rts -aI/z/ada/adsa/src/nameserver -aOZ:\ada\adsa\build\nameserver-obj -x Z:\ada\adsa\build\nameserver-obj\pcs_keygen.ali
gnatlink Z:\ada\adsa\build\nameserver-obj\pcs_keygen.ali -fPIC -g -o Z:/ada/adsa/build/pcs_keygen.exe -lzmq
built: /z/ada/adsa/build/pcs_keygen
gcc -c -IZ:/ada/adsa/src/nameserver/ --RTS=Z:/ada/adsa/build/garlic-rts -I/z/ada/adsa/src/nameserver -fPIC -g -I- -o Z:\ada\adsa\build\nameserver-obj\pcs_ctl.o Z:/ada/adsa/src/nameserver/pcs_ctl.adb
gnatbind --RTS=Z:/ada/adsa/build/garlic-rts -aI/z/ada/adsa/src/nameserver -aOZ:\ada\adsa\build\nameserver-obj -x Z:\ada\adsa\build\nameserver-obj\pcs_ctl.ali
gnatlink Z:\ada\adsa\build\nameserver-obj\pcs_ctl.ali -fPIC -g -o Z:/ada/adsa/build/pcs_ctl.exe -lzmq
built: /z/ada/adsa/build/pcs_ctl
== partition Server_Partition ==
  gcc -c --RTS=Z:\ada\adsa/build/garlic-rts -fPIC -g -gnatzr -Iexamples/gd-echo -Iexamples/gd-echo/bin/obj-server_partition -o examples/gd-echo/bin/obj-server_partition/echo.o examples/gd-echo/echo.adb
  gnatmake -m --RTS=Z:\ada\adsa/build/garlic-rts -fPIC -g -aIexamples/gd-echo -aIexamples/gd-echo/bin/obj-server_partition -D examples/gd-echo/bin/obj-server_partition -o examples/gd-echo/bin/server_partition examples/gd-echo/bin/obj-server_partition/server_partition.adb -largs -fPIC -lzmq
gnatbind --RTS=Z:\ada\adsa/build/garlic-rts -aIexamples/gd-echo -aIexamples/gd-echo/bin/obj-server_partition -aOZ:\ada\adsa\examples\gd-echo\bin\obj-server_partition -x Z:\ada\adsa\examples\gd-echo\bin\obj-server_partition\server_partition.ali
gnatlink Z:\ada\adsa\examples\gd-echo\bin\obj-server_partition\server_partition.ali -fPIC -g -o examples/gd-echo/bin/server_partition.exe -fPIC -lzmq
C:/Users/nicolas/AppData/Local/alire/cache/toolchains/gnat_native_15.2.1_346e2e00/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: Z:\ada\adsa/build/garlic-rts\adalib\s-parint.o:s-parint.adb:(.rdata$.refptr.__executable_start[.refptr.__executable_start]+0x0): undefined reference to `__executable_start'
collect2.exe: error: ld returned 1 exit status
gnatlink: error when calling C:\Users\nicolas\AppData\Local\alire\cache\toolchains\gnat_native_15.2.1_346e2e00\bin\gcc.exe
gnatmake: *** link failed.
build error: command failed: gnatmake -m --RTS=Z:\ada\adsa/build/garlic-rts -fPIC -g -aIexamples/gd-echo -aIexamples/gd-echo/bin/obj-server_partition -D examples/gd-echo/bin/obj-server_partition -o examples/gd-ech
ERROR: Command ["build/pcs_gnatdist", "examples/gd-echo/gd-echo.cfg"] exited with code 1

charlie5 · August 8, 2026, 7:13am

Hi @DrPi_Work,

Thanks for persisting. My testing under Windows was clearly less than adequate
… sorry about that. Both problems you mention should now be fixed and are released as
‘v1.5.1’. The Alire community index is being updated to ‘v1.5.1’ as well (in review as I
write this), so alr index --update-all followed by alr get adsa might be simplest by
the time you read this.

The link failure (undefined reference to __executable_start) should no longer occur.

Regarding Your prompt question — Alire PowerShell vs MSYS2 bash

alr exec -- build/pcs_gnatdist examples/gd-echo/gd-echo.cfg from the
Alire (PowerShell) prompt is the way … alr exec puts both the toolchain
and Alire’s MSYS2 tools (including a real bash) on PATH for the child
process. A bare PowerShell call instead resolves bash to the WSL relay
stub in System32 … that’s the cause of your execvpe(/bin/bash) failed error;
WSL wasn’t interfering so much as being wrongly volunteered by PATH.
pcs_gnatdist now detects that stub and tells you what to do instead of
dying cryptically. The README’s Windows section now documents the
alr exec form.

(The MSYS2-bash route you tried also works, but needs the toolchain paths
prepended manually — both the gnat_native_*/bin and gprbuild_*/bin
toolchain dirs plus /mingw64/bin for the DLLs at runtime. alr exec does
all of that for you, so I’d stay with it.)

So, after pulling:

alr exec -- build/pcs_gnatdist examples/gd-echo/gd-echo.cfg
alr exec -- bash examples/gd-echo/run_gd.sh      # -> result = 42

I also cleaned up a few compile warnings.

Thanks again for reporting … Windows is not my main OS, so I guess I’m hitting a
few teething problems.

Regards,
Rod.

DrPi · August 9, 2026, 7:38pm

Hi @charlie5 ,

Third try and… Success !!!

I’ve been able to build and run the gd-echo example on my home PC running Windows 11. I have no doubt I’ll be able to reproduce it at work.

I’ve also been able to build and run gd-echo on a RaspberryPi running the official Raspian distribution.

I’ll have questions about how to use aDSA in real world. I have to think about it before asking.

Thanks a lot for your hard work on aDSA.

Regards,
Nicolas

OneWingedShark · August 9, 2026, 8:26pm

A little organizational suggestion: perhaps inside the doc subdirectory, put a history.ref subdirectory, move those scripts there, and generate a “Readme.txt” listing the files and their significance.

I have found, at least for my own projects, that making use of a doc subdirectory for reference material helps immensely (mainly so I don’t have to hunt the file, and so I can rename it to something sensible instead of having to use the uninformative original filename).

charlie5 · August 10, 2026, 7:30am

Ah, 3rd time’s the charm, then . Glad it is now working ok.

Feel free to ask q’s or provide any other feedback. Always welcome.

charlie5 · August 10, 2026, 7:34am

I’ve categorised related examples into their own sub-folders and added a README listing each example and it’s significance. Much tidier now. Thanks for the tip.

DrPi_Work · August 12, 2026, 3:21pm

Hi,

I’m trying to determine if aDSA is suitable for my use case.
I did not had time to deep investigate aDSA functionalities so I might ask dumb questions. Sorry for that.

If I understands things correctly, in a distributed system, there are at least 3 processes. One for the server, one for the client and one for the name server. The server process and the client process communicate directly. The server process also communicates with the name server process. The client process also communicates with the name server process.
It is not clear to me what’s the name server function.

In a “static” configuration (like machines in a factory), all IP addresses are fixed and known. The launch script is easy to configure.

My use case is to control testing equipments from a Windows PC. Say, the testing equipments are oscilloscopes (this is not the case but the analogy is correct).

The testing equipments controlled by a PC are dynamically discovered (using mDNS ?) and the user selects the ones he wants to control, so the IP addresses are not “statically” known.
This implies that the aDSA processes must be launched after a discovery phase. Right ?

On the network, there can be more than one PC controlling testing equipments. Each PC controls its own testing equipments. This should not a problem if we take care of no overlap (two PCs trying to control the same testing equipment). Right ?

The PC may control two testing equipments. This implies the server process and the name server process must be located on the PC. Right ?

What about the software version running on the PC and the testing equipments ? How is the compatibility between the server process and the client process enforced ?

Regards,
Nicolas

dmitry-kazakov · August 12, 2026, 4:09pm

Please, give it a try? just in order to provide a feedback: use cases, missed features, bugs etc.

A discovery is typically made by UDP broadcast. Technically you can use single Ada task for all communications. (Ada middleware works this way).

Not necessary. It depends on the design. When using asynchronous sockets (epoll / socket select) the communication can be a single task or a pool of tasks.

That is no problem with the middleware and might be an issue with DSA in the part that relies on stream attributes. Stream attributes are non-portable. I see no way to override them in present standard. But if stream attributes get overridden, then the implementation can take care of both portability and versioning. E.g. objects can be made extendable if you have a packet with the total number of object’s stream elements. The unrecognized tail can be ignored (upward compatibility), the missed part can be filled with defaults (downward compatibility).