New verson of CLiB2 from Andrea (afxgroup)

When we can have new os4 sdk with latest features and fixes?

It will be released soon but it will contain the original clib2

Hi,

what about pthreads? I know that the current clib2 (afx) git repo pulls in Thomas Frieden, Hans-Joerg Frieden version 1.4.

The issue is that it is quite old, right and there are some missing functions needed for some things when porting.

I do not think that source code is available, only the lib and the header. Would it be an idea for us to implement pthread into this clib2?

Unlucky I cannot do more than adding a clib2 version of pthreads. If Hyperion release the code as open source we could add it into the source code and add missing functions

Edit:
On aminet there is a MOS/Aros version of pthreads. I never tested it. So a compilation/test could be useful to see if something is missing or maybe there are more functions

@afxgroup

Cross-compiling AROS/MOS version gives this error:

i've created locally a branch of a new version found on github. I've fixed all compilation errors but i need to test it. Once I'm sure with some tests that everything is working correctly maybe we can try to release a new version but at moment use the original one

I've added pthread libs into clib2 (branch pthrads) but some tests fail with strange problems (ISI/program exceptions) while some other works..
If someone wants to help the website is there.. otherwise we are stuck to the Hyperion version

Hi, I have pulled down the branch and just wanted to either report an issue, or be informed what I am doing wrong.

Firstly, I am able to compile CLIB2 without any issues. But, I expected to run "make" from the directory named "test_programs". Of course, I am in the cross-compiler environment: this is the latest adtools (https://github.com/sba1/adtools + latest 53.34 SDK). This is using gcc 11.3.

But, merely running "make" in "test_programs" does not do what I expected. The default target is "all" and the "build" directory is created, but the object files are not built at all.

I am using GNU Make 4.2.1 (bin-utils for my native Linux machine).


I do not understand this. There are no .c files in the directory where Makefile resides. This will mean that $(OBJECTS) is empty. Hence why the "all" rule does nothing more than just create a "build" directory.

I can see that most of the tests are simply files with a main function which makes sense, but I am unsure how this Makefile works even for you. I guess I am doing something wrong, but after reading the README files I still cannot see any information pointing to what I should do to run the tests.

I can also see that -ldebug is used quite often, yet when building clib2 there is no debug.a created. I can, however, see that on my Amiga NG machine with the standard SDK 53.34 there is a libdebug.a, so I am not sure where that came from.

===

Anyway, I am willing to help, but I just need to know more about my points above.

Regards.

test programs are not compiled by make. Usually you have to compile them manually (except few cases)
For manually I mean after a "make -f GNUMakefile install" that install new clib2 you have to use the common compilation format:

ppc-amigaos-gcc -mcrt=clib2 filename.c -o filename

or

ppc-amigaos-g++ -mcrt=clib2 filename.cpp -o filename -athread=native

@afxgroup

Thanks for that. I see that for some tests they are in a directory with a Makefile and for other they are standalone. I am assuming that the Makefile in program_tests should not be used, at least by me.

I basically assuming that all .c files are a standalone executable unless they are in a directory containing a makefile and going from there.

Are any of these tests pre-existing or did you write them yourself?

If I take one example: atan2.c, this just returns 0 always, and it prints out the value of errno. I am just wondering if there is good reason for this? Would it not be better to have a standardised test suite where the rule was: if the test passes it returns 0 and if it fails it returns anything but 0?

Nothing I am saying here is criticism by the way, you have done a great deal of good work. I am just asking these questions because I want to understand and help.

Thanks.

I would like to have a test suite.. but it is not possible at this moment.. I'm pratically alone in this project and I don't have the time to create a test suite from scratch.
But feel free to create one and push the request. I'll merge it

@afxgroup
I tested today the clib2 with a project and I get the following error



With the latest sba1 clib2 at the same code I get the following errors



The same code compiles fine with newlib.
So, I wonder is isnan and isinf missing from your clib2? Sorry if you already talked about them and I missed it.

@walkero

try removing the namespace "std::" most likley not in the namespace.

I think we have a problem becouse we use macros for the inline4 functions, to hide the interfaces. macros are controlled by precompiler, not the c++ compiler, so don't think a macro can be in a namespace.

I've just compiled this test

https://en.cppreference.com/w/cpp/numeric/math/isnan

without any problem
However I'm using gcc11 and i've recompiled it using my clib2 version because I suspect that c++ needs to be recompiled if you want to use correct includes (but I'm not so sure about this)

@afxgroup

Sorry for asking this dumb question, but

where can we download the correct includes for compiling programs with clib2 ?

With the original clib2, it is possible for user code to check if it is thread safe using the __THREAD_SAFE preprocessor symbol. This is/was set only when using -mcrt=clib2-ts (causes libs to be used from SDK:clib2/lib.threadsafe) and not -mcrt=clib2. Does this check still work with this replacement clib2, which I understand is thread safe by default? If not, how can it be detected at compile-time?

The context to this question is that I am doing some work on adding proper OS4 support to libcurl and it really needs to detect whether clib2 is thread safe or not, in order to allow the threaded resolver to be enabled (which needs a thread safe malloc/calloc/free).

@Futaura

Yep, things are getting complicated, with SMP we need to start worrying about syncing L2 Cache, between cores.
When working on treaded code.

@Futaura

clib2 now is always thread safe (for those functions where TS was available)

@SinanSam460

You mean c++ includes?

@afxgroup

But, how can code conditionally detect that your clib2 is in use and not the original? For example:

#if defined(__NEWLIB__) || defined(__THREAD SAFE)
// Newlib or clib-ts
#define MALLOC_IS_THREADSAFE
#emdof

Is there some other preprocessor symbol that can be checked?

I wouldn't worry if it was for my own code as I know what I'm using, but it is for open source code that needs to be compilable on multiple configurations.

I could add something if you want in the next version. For example __THREAD SAFE