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?

@joerg
Quote:

As if we didn’t know that standard newlib is open source?:) We’re talking about newlib in OS4 - the version that’s closed source with your changes and under Hyperion’s control. Yes, we could take the open-source newlib and adapt it for OS4 from scratch, but would Hyperion adopt it and replace the current one? And want we to give it to be over their control just because of ? Definitely not. There aren’t enough users or developers left to thoroughly beta-test it anyway or Hyperion take the risk for such a radical change.

Creating yet another C library—our fourth (!)—would cause an unbelievable mess. We’d just end up with another “newlib,” and what would we call it, “newlib v2”? :) The situation is already messy with clib2, clib4, and newlib. Starting another one now is absolutely a no-go. At best, we could take parts of newlib and integrate them into clib4, but that’s not so simple, and only Andrea is working on it.

Currently, nobody else is working on any other C library, and it’s honestly amazing that Andrea is dedicating his time to clib4. Just addressing the I/O issues in clib4 would already be good enough.

Yes, starting from the original newlib sources and creating a third C library as “newlib2” might make sense (and maybe if we start early it would more easy) but it starts as it starts.

In my opinion, we have no better option now (i mean now, not in ideal case) than to continue with clib4 and improve it. Even if Andrea already almost fully rewrite all the clib2 code in favor of new stuff, and even if borrow parts from opensource newlib, the name should still remain clib4 to avoid further confusion. But Andrea, along with others who’ve helped in recent years, has already made so much progress with clib4 that it’s definitely better to tackle its slow I/O than to start an entirely new port from scratch, creating more mess.

IMHO.

@NinjaCyborg
Quote:

AI help to speed up routines and casual easy stuff, but in no way will wrote for you fully specific and correct aos4 code, where every bit make sense. Surely it can help, but you still need to know what to do.

@joerg
Quote:
Why does it need to be reimplemented? Couldn't you just release it under a similar licence as the rest of newlib then others could update it without having to start from scratch. Otherwise why anybody would want to redo stuff that was already done when there is an alternative that is open source and can be updated instead of having to figure out what's missing.

Opensource OS4 newlib could be a solution, at least clib4 could benefit from some OS4 specific code and resolve I/O speed issues and maybe other tips too.

To give a little chance to Amigaos all OS4 code should be opened..

I agree 100% with all the points kas1e mentioned above, but I would like to mention a few more things about clib2 status:

- the code contains definitions that have to do with AmigaOS 3, Amiga 4 and MorphOS. But hardly any of the developers of these systems use it. MorphOS has been away from clib2 a long time ago, and AmigaOS 3 developers do not use it at all. So, maintaining any code that needs to keep support for all these systems is out of the question. One of the reasons why clib4 was created was to focus only on OS4.
- clib2 has a branch named development (https://github.com/adtools/clib2/tree/development), where Olaf is doing all his work on. His last commits were two years ago. As much as I know, they are not merged back to master because the latest changes are not tested enough by anyone. I wouldn't call it as active maintenance of a libc for our system.
- newlib is closed source and maintained by one person (salass) whenever he has time and needs.

Our goal for clib4 is not to bring confusion to the developers, but provide a better option and free them from any barriers and blocks. Instead of bitching about having to set a gcc argument for a different libc, we all should be grateful that a handful of people are doing what is needed for the development environments for our platform. They develop, they update, they test, and they benchmark as much as possible.

Currently, we have newer versions of tools available, newer and better libc free by any company and open-sourced, a better cross compiling environment for everyone to jump on, and thanks to Balaton, a cheap way to develop on any system using qemu, without the need to spend a few hundreds of money just to test a hello world code. A newer version of webkit browser would never be possible with newlib and clib2.

So, stop complaining, see the benefits and give us a hand to get into a better place. And most importantly, roll up your sleeves and start writing some new code. That's the only way to make this platform go a little bit further.

And if any of you do not like what clib4 stands for or what we develop, so be it. Try to develop with clib2 and newlib if that covers your needs. No one pushes you to use clib4, gcc11 or cmake. But others want newer tools, better editors, working debuggers and all these things that the modern development requires.

I would love hearing from one person in this community how we are going to bring Rust or Go in our systems. How will we be able to use better profiling and unit testing and more modern stuff. IMO, that's where we should focus, and not if the clib4 is a third libc or not.