Skip to content

fix: improve portability of source tree#8

Merged
EndPositive merged 6 commits intoEndPositive:mainfrom
aronson:main
Oct 19, 2025
Merged

fix: improve portability of source tree#8
EndPositive merged 6 commits intoEndPositive:mainfrom
aronson:main

Conversation

@aronson
Copy link
Collaborator

@aronson aronson commented Oct 19, 2025

Hi, I tried to run this on mobile using Android and Termux, as well as run this on macOS with my Mac and Apple clang, and it didn't build.

I updated a few things to do this:

  • I changed the submodule references to use HTTPS instead of SSH so that inexperienced users can build without being logged in to GitHub
  • I changed pthread invocations to support macOS when __APPLE__ is defined by the compiler
  • I removed the non-portable argp.h import and instead leveraged a header-only library to replace it. That argp.h header isn't available on macOS nor Android.
    • This library is a C++ header so I moved to C++11 which has decently wide support in 2025
  • I modified the picoquic submodule:
    • Termux doesn't define ANDROID when used in this config, so I instead relied on the appropriate built-in definition per the POSIX specification
    • I removed the -fno-exception flags from picoquic's CMake definitions as it broke the build given quick_arg_parser leverages C++ exceptions
  • I updated the .gitignore to ignore some files that were bugging me when working on this

EDIT: I also tested it, of course.

Server confirmed working on:

  • Ubuntu 24.04 Linux x86_64

Client confirmed working (including multipath) on:

  • Ubuntu 24.04 Linux x86_64
  • Fedora latest Linux x86_64
  • macOS 26 ARM64
  • Android 16 Termux

- fix: move submodules to https transport for portable clone
- chore: add C++ support to build
- fix: move to C++ quick_args_parser and remove non-portable argp.h include
@EndPositive
Copy link
Owner

EndPositive commented Oct 19, 2025

Hey @aronson thanks a lot for your PR! This cmake stuff is all a bit magic to me, so I'm happy to take your contributions. Can you verify that your latest version works on Mac in Docker? The Dockerfile doesn't seem to build anymore due to the __ANDROID__ change. Are you sure Termux doesn't define __ANDROID__? It seems a popular fix for running things there.

If I revert that, the Dockerfile builds but doesn't run anymore, due to the final binary not missing libstdc++.so.6. I'd be really happy if we could statically build the final slipstream binaries in Docker.

@aronson
Copy link
Collaborator Author

aronson commented Oct 19, 2025

Looks like the slipstream-picoquic Dockerfile was already broken in the original master branch. It still throws errors in make check you get with my modifications. The errors are different though it would seem! Adding the now-missing signal.h include in my new code gets me to other errors.

I'll check the rest and try to fix it for you but I can't guarantee I'll be able to fix it. The slipstream Dockerfile itself is fine even with my changes (other than a non-static libcpp as you noted). Stay tuned...

@aronson
Copy link
Collaborator Author

aronson commented Oct 19, 2025

My findings were Docker was broken out of the box in the bookworm-slim builder set up for the slipstream-picoquic library because make check was leveraging test code TUs that had symbol/ABI drift. The correct fix concerning my code was to add #include <signal.h> to picoquic so that we can get the SIGKILL symbol. I bet the more modern compilers I was using add this to the default include path for us...
After that, and in the original master branch, there were missing initializer arguments for param1 and param2 in the test code. I set those to 0. There was also another method that had some drift... I fixed those and ran the docker build...
With that change make check works now in the subproject and the docker build completes!

I think part of the reason the original slipstream didn't work in Termux is because ANDROID is not __ANDROID__. While I support the change in theory, it's still not correct as Android is not the only potential platform where _POSIX_THREAD_PROCESS_SHARED may or may not be defined (for example, tight embedded contexts, or maybe something using picolibc or nanolib with weird thread-local storage setups, I bet it's broken on PS Vita too... but it's how the spec defines it all...). I'd leave my change in and express the desired abstraction to use in a platform-independent way.

As for the missing libstdc++.so.6, I've added the right flags to link it in statically since that seems to be what you're looking for. The containers work once again:

❯ docker run --rm slipstream:latest --help
slipstream-server - A high-performance covert channel over DNS (server)

Usage: /usr/src/app/slipstream-server [options]
-l	--dns-listen-port	 DNS listen port (default: 53)
-a	--target-address	 Target server address (default: 127.0.0.1:5201)
-c	--cert	 Certificate file path (default: certs/cert.pem)
-k	--key	 Private key file path (default: certs/key.pem)
-d	--domain	 Domain name this server is authoritative for (Required)

Let me know how it looks now 🙂

P.S.: I considered porting to meson for my own reasons, but I figured it would be kinda rude to change build systems under you with my first PR. If you're open to that, it's much easier to use than CMake in my experience. I re-tooled Apotris ages ago away from make to meson and it gave us bonkers level of portability.

@aronson
Copy link
Collaborator Author

aronson commented Oct 19, 2025

Oh hold up, adding the static link to this breaks Termux! Lol! Hold off, I need to fix that, one moment... It would be better to ask for it in the Docker build's own configuration...

@aronson aronson marked this pull request as draft October 19, 2025 17:02
@aronson aronson marked this pull request as ready for review October 19, 2025 17:07
@aronson
Copy link
Collaborator Author

aronson commented Oct 19, 2025

OK that fixed it all. I guess you'll need to only use a static link to the c++ library in Docker. Tested and working as expected in Docker, Termux, bare-metal Linux, and macOS.

@EndPositive
Copy link
Owner

Amazing, indeed easier to just force static in Docker only! I'll have to look into the release GH workflow, but am holding that off if you're planning to move build systems. Would you also need to change over picoquic, or can you include cmake subprojects?

@EndPositive EndPositive merged commit 113c123 into EndPositive:main Oct 19, 2025
@aronson
Copy link
Collaborator Author

aronson commented Oct 19, 2025

You can include CMake projects (though it's a little poorly documented). I leverage this in that other project to great success for an unreleased feature branch. I'll take a stab at it soon and open a PR leveraging a new release flow for you when I can! Stay tuned...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants