Clib4 2.3

A new version of clib4 has been released:

https://github.com/AmigaLabs/clib4/releases

It contains bugfixes and a new function (malloc_usable_size) but the release is required for Odyssey to function properly.

DIRECT DOWNLOAD URL:
https://github.com/AmigaLabs/clib4/rel ... nload/v2.3/clib4-v2.3.lha

Exceptional news. Thank you Andrea for your work.

Thank you for your very hard work!

I've just tried it on my A1222 and also under qemu and Odyssey won't load any page. It launches but as soon as you enter an URL or hit a link it stops responding.

@afxgroup

Updated with this v2.3 and Odyssey 3.1 no longer starts/shows.
Reverting back to v2.1 loads Odysset 3.1 ok again.

¿need some debug output? or by using clib4 debug version.

TiA

@jabirulo

Working on it. There is a problem when no DNS are specified in internet prefs in the system and you are receiving the DNS addresses from Roadshow.
I will release version 2.4 soon

@afgroup

Ok, thx.
I do have this on my internet prefs/settings:

Well, this doesn't make any sense..

Can confirm the behaviour described by jabirulo.

I misread Jabirulo problem. I was thinking about DNS not resolved. Wait for new Odyssey version so

@hotrod we are in the same condition, I've tried to post in Odyssey thread but I didn't have success in obtain a working 3.1.0 version, I'm currently stick with 1.23

@afxgroup

I've been tinkering for the past few weeks trying to get Half-Life, or more precisely the Xash3D FWGS engine reimplementation, running on AmigaOS4. Using clib4 as the CRT, built with the GCC13 toolchain from walkero's Docker image. Testing has mostly been under QEMU (Pegasos 2, AmigaOS 4.1 FE), and I've also poked at it a bit on my X5000.

Getting here was honestly a lot of trial and error. The engine, client, and game DLLs (hlsdk-portable) all build cleanly now. I had to build SDL2 for clib4 myself (the SDL2 branch of AmigaPorts/SDL, since there wasn't a ready-made clib4 build). Along the way I ran into the usual AmigaOS4 gotchas: dlopen() couldn't find its own .so files because the working directory at startup isn't necessarily the program's directory, so I had to explicitly switch to PROGDIR first. Then there was a missing stack cookie, since the default stack was too small. And a small but annoying bug in the engine itself - it was identifying itself as "unknown" instead of "amigaos4" when building library filenames, simply because that case was never added in the code. On top of that, a path bug that produced "PROGDIR:/valve/..." instead of "PROGDIR:valve/..." - looks harmless at first glance, but elf.library just can't find the first one.

The game gets pretty far these days: the server DLL loads, the software renderer initializes, and it starts loading the menu.

Right now I'm stuck on something that looks like a genuine clib4 bug. dlopen() crashes with a DSI on the very first call, as soon as the GCC13-toolchain's own libstdc++.so is involved. To narrow it down I wrote a tiny test program - literally just one dlopen() call and nothing else, no engine, no other code around it. And sure enough, it crashes exactly the same way. That's when it became clear this had nothing to do with our own code and sits somewhere deeper. Traced it through the crash log and some disassembly, and it looks like IClib4 stays NULL because the constructor in libc.so that's supposed to initialize it never gets called. Filed it here:

https://github.com/AmigaLabs/clib4/issues/448

I also reproduced this on the X5000, not just under QEMU - exact same crash. So it's not some emulation quirk, it's a real issue with the current clib4/toolchain combo.

When I tried swapping in the old AmigaOS4.1 system libstdc++.so instead, the crash went away - but then it breaks somewhere else, because that old library uses a different exception-handling model (SjLj instead of DWARF) than the current toolchain. So they clash with each other either way, I don't currently have a libstdc++.so that works for both.

If anyone's run into something like this before, or has an idea for a workaround, I'd be glad to hear it. Once I get past this I'll happily post a test build here too. The OpenGL renderer is also acting up under QEMU ("Invalid OpenGL version") - curious whether that shows up on the X5000 with real hardware once I get that far.

Will keep this thread updated.

@Maijestro
I am not sure if it is possible, but have you tried to use the gcc11 instead of gcc13, and see if you get the same situation there? As the gcc11 is more years under testing from developers, I would trust it more against the gcc13. At least to exclude that it is a gcc13 issue.

@walkero

Quote:

Yes, I can confirm that I recompiled it with gcc11/clib4 and had no issues. So it's a bug in gcc13 with the test case I described, in the hope that it might be fixed later.

Thanks for the help and for the great work on Docker.

@Maijestro
Half-Life !!!


Maybe not a Clib4 2.3 comment but -

Half-Life !!! :)