How to use clib4 (natively)?

I decided to try out clib4. I've downloaded and installed it. Now how do I actually use it.

The compiler complains that -mcrt=clib4 is an invalid C runtime library.

I haven't found the documentation needed to make it work.

Hans

@Hans
You did everything alright, but you need updated adtools that support -mcrt=clib4. You can either build the latest version from SBA's page (https://github.com/sba1/adtools), which includes all the changes to make -mcrt=clib4 work, or you can use the one from (https://github.com/AmigaLabs/adtools/commits/master/), which has a few more fixes on top. In general, SBA's version is fine too

Be aware, though, that the "stdio" part borrowed from clib2 is very slow (e.g., console I/O, file I/O) compared to newlib. This is the last remaining issue to address. There’s a ticket with details if you’re interested: https://github.com/AmigaLabs/clib4/issues/276. You can also check the OS4-beta for Olaf’s answers about why it’s slow.

In other aspects, clib4 is a lifesaver. Andrea built the new Odyssey with it, and we’ve used it to build GDB, the latest binutils, and I ported Payback before and built the latest wget with it lately, among other things. Threading support has been greatly improved, along with many other enhancements. You can install the tagged version (currently 1.6), but Andrea’s daily work is in the 'development' branch if you want to stay up to date.

Once issues with SlowIO deal with, that will be 100% choose #1.

@kas1e

Thanks. Is there a readily downloadable updated adtools? I'm working on beginner instructions, and "you need to compile your own native adtools" is NOT beginner friendly.

If not, then clib4 still isn't ready for general use. Ideally it would be in the next SDK... as the only C runtime library. Having multiple runtime libraries is messy.

Hans

@Hans
I always prefer to build my own setup and dive deep into scripts and shell commands, but George (Walkero) creates Docker images and updates them periodically with all the latest tools (adtools, clib4, and other third-party libraries). I'm sure he'll respond once he sees this topic.

As for the SDK, it's probably not that simple. Hyperion is already busy with everything, and maintaining another C library would likely be too much for them, in my opinion. However, since the SDK uses the Adtools repo to build GCC, support for -mcrt=clib4 will definitely be included by default. At most, you'll need to download and install clib4. This approach, in my opinion, keeps the SDK simpler and easier to maintain. For other needs, there are Docker images available if someone wants them (just my opinion, of course).

@kas1e

I'm trying to build stuff natively on AmigaOS 4 itself.

Sure, I could use George's docker images (which I featured in videos on how to set up a cross-compiler). However, if we keep doing things half-assed then we're going to both lose the ability to build most stuff natively, AND getting newcomers involved in OS4 development will become impossible.

I've just spent over a day trying to get an OS4 port to build. That same code builds out-of-the-box in minutes on all major platforms.

Hans

@Hans
Quote:

George is working on a native add-on for the SDK that will include clib4 and other components, so it can be used if needed. It should be released soon for those who require it.

Quote:

While I'm not advocating for anything specific, in my opinion, building modern projects on OS4 with an "out-of-the-box in minutes" experience, like on major platforms, is not feasible and likely never will be. This is due to issues in tools like CMake and Python that often go unnoticed because of the small user base until someone raises the alarm. Additionally, differences between Unix and AmigaOS paths contribute to the problem. Of course, it’s all possible, but it’s more difficult and time-consuming.

When I want to build something written specifically for AmigaOS 4, native building is certainly possible, easy, and fast (as long as it doesn’t involve large, non-native cores). However, if you aim to build projects like Odyssey, GDB, or Qt with the same "out-of-the-box" ease as on major platforms, you’ll almost certainly fail. This is because of the issues mentioned, as well as performance limitations. In these cases, a cross-compiler is the only viable solution.

Native building is great and appropriate, especially for code using native OS4 APIs. However, it’s not practical for porting large modern projects that consume gigabytes and rely on constantly evolving build environments. Cross-compilers, at least, can keep up with those demands.

To me, Hans' feedback has much value, from an user point of view and knowing he is also an experienced Amiga developer.

From the beginning, I globally encourage the work to contribute and improve developing tools but I disapproved the way we will see the installation of a third unsatisfying libc ... instead of two.

Programming on Amiga is already not that fast but we are making the situation more complex, putting great efforts on same things but ... differently.

I regret that we can't improve faster our official libraries. But I still think that the right way is to experiment like what is done in amigalabs but ... backporting things that have been proved to be good.

@corto
If we lived for 1,000 years, or if you created a Hieronimouse for just 2 months instead of 10 years :) then yes, everything you say would be absolutely true. Ideally, we’d have one unified C library, like newlib, that:

- Supports everything.
- Be fast enough.
- Updated very frequently.
- Fixes only reported bugs.
- Responds to developers’ questions and provides explanations.

In that case, you’d be absolutely right.

However, in reality, we live for 60–80 years at most, only a fraction of which we’re in a productive working state. This means we can’t wait 10 years for Hyperion to resolve their issues, find someone to improve the closed-source newlib, or address our questions. So, that option is off the table for now. Will it improve someday? Great. If not, we’re not waiting any longer.

You also suggest improving clib2, but Olaf has clearly stated clib2’s intentions. Neither clib2 nor newlib aims to provide full support for modern POSIX features that would help us port software. None of them properly collaborate with adtools anymore to stay up-to-date with changes, avoiding conflicts with new includes, new GCC versions, and other updates, simple no one care and have no time. So, what should we do? Wait for whom? Do what?

This is why clib4 was created—because Andrea has the time and motivation to tackle it all. In the end, this has proven beneficial: we can now port and achieve things that were impossible with clib2 or newlib and likely never will be due to the issues mentioned (of course everything posible, just with newlib and clib2 something will take so much additional time to reimplement the wheel again and again).

While your perspective is ideal in theory, reality dictates a different approach.

Nobody is stopping anyone from taking parts of clib4 and contributing them to clib2, if someone steps up and Olaf will agree with (he probably will not, as you read in os4beta, clib2 wasn't purposes for what we want it to be). Or from working on newlib to bring it up to par with modern C libraries. Or even from creating a brand-new, unified library that would replace all others and outperform them. Nobody’s stopping that, right? So, for now, clib4 is here. :)

With clib4, I can simply talk to Andrea, explain issues, and he fixes bugs, improves it, and adds new features without worrying about 68k support or hearing “we don’t support this or that.” It’s all open source, and anyone can contribute. You might ask, why not clib2? Because Olaf wants it to stay true to its original purpose.

Clib4 is one of the C libraries currently under active development. Both newlib and clib2 have been stagnant for years, receiving mostly minor updates, if any.

If you have any better solutions, please share them. For now, we haven’t found anything better than moving forward with a new open-source C library like clib4. Of course, if someone doesn’t need it, they can always use clib2 or newlib—no problem there.

@Hans
Quote:Yes, and that was one of the reason I insisted to add a clause in my newlib contract that support for clib2 has to be removed from adtools (at least in all versions of it distributed by Hyperion).
But, just like for nearly everything else, Hyperion broke the contracts...

@kas1e
Quote:Not modern any more, about 15 years ago, but I never used a cross-compiler for any of my AmigaOS 4.x development, incl. OWB.
And yes, it was very slow, a complete rebuild of it on an A1XE or even worse on my Sam440ep (too few RAM, paging involved) had to be started on an evening to have some results, at best, on the next morning...

@kas1e
Quote:Sigh. I've posted it several dozens times already, and this time it's the last one: Newlib is open source: https://www.sourceware.org/newlib/
Only the very small AmigaOS 4.x specific parts I implemented are closed source.
Work required for re-implementing all of my AmigaOS 4.x parts, depending on the skills of the developer, about 25-100 man hours, which is much less than the time already spend on clib4...

This thread is a great example of the barriers to entry for Amiga development.

The OS4 SDK that's available is great in terms of a one click install everything. The new OS3 NDK would do well to take lessons from that.

Trouble is, once you start to use it you discover that it's massively out of date, you don't have the new, working versions of lots of stuff, have wrong header files and so on, and to get the newer ones you have to be on the insiders clique of OS4 beta testers, sign an NDA/non aggression pact etc.

OS3 the problem is different - you either have to source a pirate copy of SAS/C, put up with ancient GCC or get VBCC installed and configured. Even then, everyone installs everything in different places on their work: drives so forget about collaborating with other people. No one in Amiga land seems to have heard of 'configuration management' and I don't just mean svn/git I mean Developer eXperience.

Or, as Hans says, you're stuck with building everything yourself using cross compilers and other things one shouldn't have to fuss with.

Back in 2003 I tried to use clib2 for 68k as it was at the time, together with GCC, actually GCC3 or 4 IIRC since 2.95 was too old to work with the Python code base, to update Amiga Python from Irmen de Jong. I got part of the way but it was just too much debugging the toolchain and not enough working on the actual port I eventually gave up. Here in 2025 the situation has hardly improved!

@joerg

Could an AI agent help?