search

pflarue / ardop

ardopcf - A multi-platform implementation of the Amateur Radio Digital Open Protocol (ARDOP)
Other
30 stars 7 forks source link

Prepare for v1.0.4.1.3 #110

Open pflarue opened 5 days ago

pflarue commented 5 days ago

I intend to produce a new release of ardopcf v1.0.4.1.3 soon. This will incorporate everything currently in the develop branch as well as a few additional minor changes that I intend to push in the next few days. This will include removal of command line options that were marked as deprecated in v1.0.4.1.2.

@cbs228 and anyone else: If you have any additional changes you would like to have included in this next release, please add a comment here, and plan to create a pull request in the next couple of days.

@radio-miskovice has also inspired me to make at least some minimal improvements to the documentation before creating the new release. His contribution in PR #109 is an excellent start to this. Pull requests for documentation changes should generally be direct to the master branch, and they won't change the binaries produced for the next release. So, if @radio-miskovice or anyone else would like to contribute additional documentation changes, they do not need to be submitted before the next release. However, I intend to do a little bit of documentation work before the new release so that anyone who visits the GitHub repository in response to announcements of the new releases will at least find a simpler main README.md with links to other pages containing additional documentation.

cbs228 commented 4 days ago

One thing we should definitely do is to report the glibc minimum version required for any Linux binaries, if provided. Binaries built on Ubuntu 24.10 will not run in Ubuntu 12.04. The glibc version depends entirely on the host OS; you can find it in the output of:

$ ld --version
GNU ld (GNU Binutils for Debian) 2.31.1

For this reason, most portable Linux binaries are built in a container image for the oldest still-supported distro. (The runners used for Github Actions are all very new, so this is still true if you are using Github Actions runners.)

pflarue commented 4 days ago

@cbs228, thanks for that info. I was unaware of this. It seems that every day I learn something that I didn't know that I didn't know.

I've been building binaries using the systems I have, and assuming that anybody running Linux on similar hardware could use them. I'm now a little surprised that nobody has reported problems with trying to run the Linux binaries I've previously released. Maybe most Linux users already understand this issue, and compile from source if my binaries don't work?

This further reinforces my interest in ensuring that building from source remains as simple as possible as a fallback for anyone with an older glibc than mine.

cbs228 commented 4 days ago

I've been building binaries using the systems I have, and assuming that anybody running Linux on similar hardware could use them.

The greatest trick C ever pulled was convincing the world it doesn't have a runtime environment. It very much does. This is why Linux packaging tends to take one of two routes:

A third option is to build with musl instead of glibc and to statically link absolutely everything. Alpine containers are useful for this. There are significant drawbacks to this approach, but it can be made to work.

pflarue commented 3 days ago

I have an older Windows laptop with WSL Debian with glibc version 2.31.1. I also prepared SD cards for 32 and 64 bit raspberry pi images with Raspios Buster that also use glibc version 2.31.1. If I understand correctly, binaries built with these should work on any OS that is no older than these, but anyone using an even older OS will need to compile from source. I'll put comments to this effect in the next release announcement. I think that these are old enough to cover most likely users.

I've built ardopcf on these three systems, and will be testing the resulting binaries on my more up to date systems.