ComposersDesktop
Fixed various incompatibilities so it would compile for Termux
Trying to find some way of replicating the timer function in dev/externals/fastconv/fconv.cpp since sys/timeb.h doesn't exist in Android's bionic C library nor in OpenBSD but this is all that made it compile in my phone up to that poimt
So apparently <sys/timeb.h> has been scrapped from Glibc since 2023 and now I'm trying to change over all usage of <sys/timeb.h> with clock_gettime().
This is all very useful information and suggestions. Please remember though that this code is required to build and run not only on Linux but on other primary OSes and compilers, including Visual Studio and other Windows compilers. It is great to be able to add Android to that list. Please wrap all such suggested changes under compiler conditionals, whether “linux” or “GLIBC”, and not simply removing the original code, which for the time being (ho ho) needs to continue to be available.
Clearly functions handling time are tending to change, across platforms, and one way or another the program code needs to remain portable to all supported platforms. In the main CDP code set this is handled in “osbind.c” where custom functions use platform-specific code internally. Fastconv is a standalone program, but ostensibly needs the same approach.
RD.
On 29 Aug 2025, at 22:29, VISΛGE @.***> wrote:
Trying to find some way of replicating the timer function in dev/externals/fastconv/fconv.cpp since sys/timeb.h doesn't exist in Android's bionic C library nor in other NIXes but this is all that made it compile. You can view, comment on, or merge this pull request online at: https://github.com/ComposersDesktop/CDP8/pull/20 Commit Summary • 4620d0f Wrote compilation note for libaaio • 5697ec0 Changed incorrect definition of POS64 for Linux systems that don't use GLIBC • a6d722e Changed S_IWRITE and S_IREAD to their POSIX-supported counterparts File Changes (7 files) • M dev/externals/mctools/chxformat.c (2) • M dev/externals/portsf/portsf.c (2) • M dev/newsfsys/pvfileio.c (4) • M dev/newsfsys/sfsys.c (6) • M dev/pvxio2/pvfileio.c (4) • M dev/sfsys/sfsys.c (6) • A libaaio/README.md (11) Patch Links: • https://github.com/ComposersDesktop/CDP8/pull/20.patch • https://github.com/ComposersDesktop/CDP8/pull/20.diff — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.**>
Considering clock_gettime() is the current standard way of gathering information about time, I think we should handle this with CMake via either checking for <sys/timeb.h> or a simple -DNO_TIMEB option.
It’s not standard in Visual C++. It’s a POSIX function, and VS has never supported that natively.
VS has an almost identical equivalent “timespec_get(), with arguments swapped compared to clock_gettime().
Whether that is enough to make a thin wrapper function is a question I can’t answer yet.
And while I own machines running Windows, Linux and MacOS (including an M2 box), as I am alone supporting all those platforms, and find those considerably more than enough to deal with, I am disinclined to add Android support to that collection just yet. I can happily direct Android users/developers to your fork, which seems a pretty reasonable github-ish thing to do (we have a lot of ports now!). RD.
On 31 Aug 2025, at 12:15, VISΛGE @.***> wrote:
visagemsc left a comment (ComposersDesktop/CDP8#20) Considering clock_gettime() is the current standard way of gathering information about time, I think we should handle this with CMake via either checking for <sys/timeb.h> or a simple -DNO_TIMEB option. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
I do understand it if you don't want to directly support Android and now I see that ftime holds a bigger place in the world than I thought but please do consider adding those first 3 commits in. There are distros like Alpine Linux and glaucus which don't use GLIBC as their main C runtime. I don't really have any justification for S_IWUSR and S_IRUSR besides just being up-to-date with the current POSIX conventions as you can never guess when they'll be removed too.
Alpine Linux
I started making a build script for CDP8 for Alpine Linux and the similar distro Chimera Linux, but it would take a long time to set up because Alpine Linux and Chimera Linux do not provide packages containing builds of the static library of portaudio, only the shared library (and this is something that this PR does not currently address), so my preferred solutions to that are one of the following:
I could either edit CDP8 to link to the shared library instead of the static library, or I could write steps for downloading the source code of each operating system, recompiling its portaudio package with the static libraries enabled, and reinstalling the package.
I'm not personally a big fan of other solutions like compiling an entire copy of all of the source code of PortAudio within the build system of CDP8 instead of the build system of the operating system, because some operating systems add specialized patches or settings into their packages of PortAudio that would not be present unless specifically preserved, which could cause that copy of PortAudio, and therefore also the build of CDP8 linked to it, to not work in ways that might be difficult to predict. However, it is possible to set up that way as a last resort, because an alternative approach that would work is to first set it up that way, and then write steps showing how to manually collect and apply any operating-system-specific PortAudio patches and build settings into the vendored PortAudio on a case-by-case basis.
I have paused working on ports of CDP8 to Alpine Linux, Chimera Linux, FreeBSD and OpenBSD because I noticed that nobody has asked for CDP8 on those operating systems, so there might be no users, but if someone wants it on one of those they can ping me and I might make it for them.
