Steps to implement the distributed annex from scratch

They could go to extreme and do it the Windows’ way by simply installing everything… :grinning:

I use a lot of Linux distributions, but none for developing. Windows is more comfortable to me. It is Ada’s strength that you can develop anywhere you wanted and it will seamlessly work everywhere. Usually I do not even test all the targets and rely on Ada.

I agree the docs are often poor and the lack of installer is painful. About 10 years ago, I made an Arch derivative (‘laceOS’) which consisted of a very simple text based installer (answer 5 simple questions and xfce4 and gnatsudio and all then available, common Ada packages were installed). It was intended to be an easy start Ada dev environment. Final user base was … 2 (including myself :slight_smile: ).

I initially chose Arch since I wanted the latest possible package versions. I’ve recently considered reverting to XUbuntu several times, esp since Alire now makes my Arch AUR Ada packages largely redundant.

How? Either Alire packages everything, which it does not, or runs on top of a target packaging system, automatically rewrapping packages.

So far Alire is unable to package simple components, or at least I have no idea how to do it. BTW, I looked your package of the simple components. It is incorrect because i686 and x86_64 architectures need to switch a lot of sources. ODBC is different on the API level for both. Atomic access to 64-bit units is absent in 32-bit GNAT etc One can do that in PKGBUILD by scripting lsb_release. In Alire? No idea. If I ran the circus, I would generate a gpr-package with variables describing the target and the compiler capabilities. Fedora’s Ada policy has something alike, which is very useful.

I’ve just added description for receiver stub of RCI (remote call interface). Take a look.

Alire generates a project file with the host OS, architecture and distribution. I don’t know what you mean by compiler capabilities, but if it is not supported, an issue could be opened explaining the necessity. If it’s for cross compilation, I’ve seen issue #2067, which contains links to other implemented and still open issues.

abstract project Coap_Spark_Config is
   Crate_Version := "0.10.0-dev";
   Crate_Name := "coap_spark";

   Alire_Host_OS := "linux";

   Alire_Host_Arch := "x86_64";

   Alire_Host_Distro := "ubuntu";

2 Likes

Which features are implemented, for example. A lot of people try new language features to discover that the compiler does not support them. They could add checks in their projects to prevent end user confusion.

My particular issue is whether the pragma Atomic works on Stream_Element_Offset. If it does not, then if there are gcc atomic primitives available, if not then it falls back to protected objects.

What have the crate name and version to do in this? Why is it named after the crate? Why is it host OS, architecture and distribution? I do not care about these on the host, I do about the target. Otherwise it looks promising.

The purpose is to use this project in the user project to select sources and compiler/linker options.

I saw in another discussion means to prevent Alire from hallucinating, pardon, generating gpr-files. If that works and the project above is still generated, then the only remaining issue to me is automated uploading of releases.

Sorry for the delay. It is near impossible to work with hammering and power tools constantly breaking concentration :slight_smile: .

Tbh, I’m not that familiar with Alire, esp in regard to how it interacts with preexisting OS system packages.

Have you had any luck packaging Simple Components for Arch ? I’ve managed to build your demo by extracting the source tarball into the src folder but it sort of swamps the dsa demo files, making it a little hard to navigate in a file browser.

This is excellent !

I’ve built the project, added a few debug lines (via standard_Error) and using a fifo pipe have the client call the remote server function and display the resultant text.

$ mkfifo my_loop

$ ./demo/bin/client < my_loop | ./demo/bin/server > my_loop
Server: reading parameter stream.
Server: writing result stream.
Client: 'Hello, World'.

I’m starting to grok the internal details reasonably well and look forward to more experiments and eventually trying to expand and then wed your example to Dmitri’s DSA solution.

Can we get some docs (not implementation infected with the GPL) on what you have to provide to build a DSA implementation? Maybe include non-licenced specs like the rm’s do.

Yes. It is quite easy except for the package description key which is not a description at all as I falsely suggested, but some sort of a list of topics. Then was the PKGBUILD parser which was unable to ignore spaces in the dependencies list.

I did it in a way I consider right, e.g. no any build stuff. One binary package with one *.so file. One developing package with a, ads, ali, gpr. I plan to support x86_64, ARM 64, maybe, ARMv7 (32-bit).

Move it into a separate directory and list that in the ADA_PROJECT_PATH.

1 Like

It seems that Arch does not support Ada on ARM.

Archlinux is for prebuilt x86_64 binaries and archlinuxarm.org is for ARM prebuilt binaries. But it doesn’t matter for user packages (AUR). You add the relevant architectures to the arch field in PKGBUILD like arch=('x86_64' 'aarch64').

Note: I don’t have ARM hardware, so never tested.

I have ARM hardware. Neither armhf (32-bit) nor aarch64 Arch have the gcc-ada package.

Wouldn’t it be better to use gentoo instead of arch? It has support for many architectures, a cross compilation handler and the alr dev branch has gentoo support. There is also a special category for ada in the gentoo package repo. dev-ada – Gentoo Packages

There’s still a lot of binary packages which need the gentoo option adding.

It is not one or another. I add distributions if they are popular. Currently I have Debian, Ubuntu, Fedora and CentOS. I add Arch because it seems that some people like it.

Gentoo? I might consider it. But it is a yet another packaging system, which is a lot of work to adjust the scripts. Unfortunately I was too lazy to write them in Ada and now all this bash mess hits me back hard. Then I generally mistrust the BSD line. I had only poor experience with it.

Are you sure Gentoo supports Ada on ARM?

Yeah.

I personally don’t use arm but according to the docs it works. Ada-bootstrap is stable for arm and arm64. GPRbuild and other tools are also available but they are all in testing. You can also add ada to gcc by adding the “ada” use flag (I did that to make a cross compiler).

But I am not so knowledgeable about gentoo because I just switched to it about a month ago.

See above. I posted the output of eix -I gcc, although, just noticed Ada is not enabled on that build, trying it now.

So, according to this:

dev-ada/gprbuild – Gentoo Packages

actually supported are Intel 64-/32-bit and ARM 64-bit. It looks that GtkAda is packaged too, which is nice.

Ok, that didn’t build.

Adding multilib support to Makefile in /var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-15-20251122/libstdc++-v3
with_multisubdir=thumb/v8.1-m.main+pacbti+mve/bp/hard
config.status: executing libtool commands
config.status: executing generate-headers commands
make[2]: Entering directory '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/build/arm-none-eabi/thumb/v8.1-m.main+pacbti+mve/bp/hard/libstdc++-v3/include'
echo timestamp > stamp-pb
echo timestamp > stamp-host
make[2]: [Makefile:1838: arm-none-eabi/bits/largefile-config.h] Error 1 (ignored)
make[2]: [Makefile:1839: arm-none-eabi/bits/largefile-config.h] Error 1 (ignored)
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
echo 1 > stamp-dual-abi
echo 1 > stamp-cxx11-abi
echo 1 > stamp-allocator-new
echo 'undef _GLIBCXX_USE_FLOAT128' > stamp-float128
sed -e '/^#pragma/b' \
    -e '/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_GLIBCXX_\1/g' \
    -e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
    -e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \
    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
    < /var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-15-20251122/libstdc++-v3/../libgcc/gthr.h > arm-none-eabi/bits/gthr.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
    < /var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-15-20251122/libstdc++-v3/../libgcc/gthr-single.h > arm-none-eabi/bits/gthr-single.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
    -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
    < /var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-15-20251122/libstdc++-v3/../libgcc/gthr-posix.h > arm-none-eabi/bits/gthr-posix.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
    -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
    < /var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-15-20251122/libstdc++-v3/../libgcc/gthr-single.h > arm-none-eabi/bits/gthr-default.h
make[2]: Leaving directory '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/build/arm-none-eabi/thumb/v8.1-m.main+pacbti+mve/bp/hard/libstdc++-v3/include'
config.status: executing libtool commands
config.status: executing generate-headers commands
make[2]: Entering directory '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/build/arm-none-eabi/libstdc++-v3/include'
echo timestamp > stamp-pb
echo timestamp > stamp-host
make[2]: [Makefile:1838: arm-none-eabi/bits/largefile-config.h] Error 1 (ignored)
make[2]: [Makefile:1839: arm-none-eabi/bits/largefile-config.h] Error 1 (ignored)
echo 0 > stamp-namespace-version
echo 1 > stamp-visibility
echo 1 > stamp-extern-template
echo 1 > stamp-dual-abi
echo 1 > stamp-cxx11-abi
echo 1 > stamp-allocator-new
echo 'undef _GLIBCXX_USE_FLOAT128' > stamp-float128
sed -e '/^#pragma/b' \
    -e '/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_GLIBCXX_\1/g' \
    -e 's/_GLIBCXX_SUPPORTS_WEAK/__GXX_WEAK__/g' \
    -e 's/_GLIBCXX___MINGW32_GLIBCXX___/__MINGW32__/g' \
    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
    < /var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-15-20251122/libstdc++-v3/../libgcc/gthr.h > arm-none-eabi/bits/gthr.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
    < /var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-15-20251122/libstdc++-v3/../libgcc/gthr-single.h > arm-none-eabi/bits/gthr-single.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
    -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
    < /var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-15-20251122/libstdc++-v3/../libgcc/gthr-posix.h > arm-none-eabi/bits/gthr-posix.h
sed -e 's/\(UNUSED\)/_GLIBCXX_\1/g' \
    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCXX_\1/g' \
    -e 's/SUPPORTS_WEAK/__GXX_WEAK__/g' \
    -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*USE_WEAK\)/_GLIBCXX_\1/g' \
    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
    < /var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-15-20251122/libstdc++-v3/../libgcc/gthr-single.h > arm-none-eabi/bits/gthr-default.h
make[2]: Leaving directory '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/build/arm-none-eabi/libstdc++-v3/include'
make[1]: Leaving directory '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/build'
make: *** [Makefile:1068: all] Error 2
 * ERROR: cross-arm-none-eabi/gcc-15.2.1_p20251122::crossdev failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=cross-arm-none-eabi/gcc-15.2.1_p20251122::crossdev'`,
 * the complete build log and the output of `emerge -pqv '=cross-arm-none-eabi/gcc-15.2.1_p20251122::crossdev'`.
 * The complete build log is located at '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/temp/environment'.
 * Working directory: '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/build'
 * S: '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-15-20251122'
 * 
 * Please include /var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-build-logs.tar.xz in your bug report.
 * 

>>> Failed to emerge cross-arm-none-eabi/gcc-15.2.1_p20251122, Log file:

>>>  '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/temp/build.log'

 * Messages for package cross-arm-none-eabi/gcc-15.2.1_p20251122:

 * ERROR: cross-arm-none-eabi/gcc-15.2.1_p20251122::crossdev failed (compile phase):
 *   emake failed
 * If you need support, post the output of `emerge --info '=cross-arm-none-eabi/gcc-15.2.1_p20251122::crossdev'`,
 * the complete build log and the output of `emerge -pqv '=cross-arm-none-eabi/gcc-15.2.1_p20251122::crossdev'`.
 * The complete build log is located at '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/temp/environment'.
 * Working directory: '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/build'
 * S: '/var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-15-20251122'
 * Please include /var/tmp/portage/cross-arm-none-eabi/gcc-15.2.1_p20251122/work/gcc-build-logs.tar.xz in your bug report.
rogue ~ # gc -v
^C
rogue ~ # gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-15.2.1_p20251122/work/gcc-15-20251122/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python --enable-languages=c,c++,fortran,ada,m2 --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 15.2.1_p20251122 p3' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-offload-defaulted --enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp --enable-libada --enable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --without-isl --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --disable-fixincludes --with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-build-config=bootstrap-cet
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.2.1 20251122 (Gentoo 15.2.1_p20251122 p3) 

Bug sumitted