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.