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
Cross-compiling AROS/MOS version gives this error:
In file included from /usr/local/amiga/ppc-amigaos/SDK/include/include_h/exec/libraries.h:16,
from /usr/local/amiga/ppc-amigaos/SDK/include/include_h/utility/utility.h:16,
from /usr/local/amiga/ppc-amigaos/SDK/include/include_h/proto/exec.h:13,
from semaphore.c:21:
semaphore.c:42:5: error: ‘&semaphores’ is a pointer; did you mean to use ‘->’?
42 | NEWLIST(&semaphores);
| ^~~~~~~
semaphore.c:42:5: error: ‘&semaphores’ is a pointer; did you mean to use ‘->’?
42 | NEWLIST(&semaphores);
| ^~~~~~~
semaphore.c:42:5: error: ‘&semaphores’ is a pointer; did you mean to use ‘->’?
42 | NEWLIST(&semaphores);
| ^~~~~~~
semaphore.c:42:5: error: ‘&semaphores’ is a pointer; did you mean to use ‘->’?
42 | NEWLIST(&semaphores);
| ^~~~~~~
semaphore.c:42:5: error: ‘&semaphores’ is a pointer; did you mean to use ‘->’?
42 | NEWLIST(&semaphores);
| ^~~~~~~
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.
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
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:
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.
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
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
In file included from /MDH1/SDK/gcc/include/c++/8.4.0/cmath:45,
from externals/picojson/picojson.h:45,
from lib/cppcheck.cpp:58:
externals/picojson/picojson.h: In constructor 'picojson::value::value(double)':
externals/picojson/picojson.h:200:8: error: '__isnan' is not a member of 'std'
std::isnan(n) || std::isinf(n)
^~~~~
externals/picojson/picojson.h:200:8: note: suggested alternative: '__ioinit'
externals/picojson/picojson.h:200:25: error: '__isinf' is not a member of 'std'
std::isnan(n) || std::isinf(n)
^~~~~
externals/picojson/picojson.h:200:25: note: suggested alternative: '__ioinit'
With the latest sba1 clib2 at the same code I get the following errors
In file included from /MDH1/SDK/gcc/include/c++/8.4.0/cmath:45,
from externals/picojson/picojson.h:45,
from lib/cppcheck.cpp:58:
externals/picojson/picojson.h: In constructor 'picojson::value::value(double)':
externals/picojson/picojson.h:200:8: error: expected unqualified-id before '(' token
std::isnan(n) || std::isinf(n)
^~~~~
externals/picojson/picojson.h:200:8: error: expected primary-expression before 'float'
std::isnan(n) || std::isinf(n)
^~~~~
externals/picojson/picojson.h:200:8: error: expected primary-expression before 'double'
std::isnan(n) || std::isinf(n)
^~~~~
externals/picojson/picojson.h:200:8: error: expected primary-expression before 'long'
std::isnan(n) || std::isinf(n)
^~~~~
externals/picojson/picojson.h:200:8: error: '_Generic' was not declared in this scope
std::isnan(n) || std::isinf(n)
^~~~~
externals/picojson/picojson.h:200:25: error: expected unqualified-id before '(' token
std::isnan(n) || std::isinf(n)
^~~~~
externals/picojson/picojson.h:200:25: error: expected primary-expression before 'float'
std::isnan(n) || std::isinf(n)
^~~~~
externals/picojson/picojson.h:200:25: error: expected primary-expression before 'double'
std::isnan(n) || std::isinf(n)
^~~~~
externals/picojson/picojson.h:200:25: error: expected primary-expression before 'long'
std::isnan(n) || std::isinf(n)
^~~~~
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.
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.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
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)
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).
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.