With this in mind, would it not make more sense for your clib2 libs to belong in SDK:clib2/lib.threadsafe opposed to SDK:clib2/lib? And then -mcrt=clib-ts would be used to use your library and that also means __THREAD_SAFE will be defined by the compiler. I've checked and -mcrt=clib2-ts still works and links fine with GCC 11. I mean your library is technically replacement for the old clib2-ts (I still have it installed!), not clib2, IYSWIM.
We can't add a new clib2 and try to maintain everything in parallel with old version. My version should be a replacement of new one. Otherwise it is better to change the name to the lib.. So i've already defined in a new branch __THREAD_SAFE and you will be sure that clib2 will have TS enabled if you need it
And also if you plan to compile something for tabor remember that clib2 doesn't support SPE and since I don't have any tabor I can't implement/test any change. So it is better to use newlib for this purpose
Just added libcrypt to clib2. Now crypt and crypt_r are supported. In the README.md all the informations. I've also added __THREAD_SAFE and some new functions I'll release a new beta soon. If someone wants to help me with pthreads there is a branch with pthread library that at moment works except if you use pthread_exit in the thread function..
I tried to port back in past few ncurses based prods, like for example NCurses based hexviewer and GDB frontend, but they all have bugs and crashes because when i use opensource ncurse implementations.
On which one your support based on ? Your custom ones or something opensource in the wild?
Nice! I really was beginning to wonder why NCurses (or OpenNCurses) hadn't been ported, what I also wonder over is the name of clib2, why not change it to clib3? then you could have old clib2 and new better clib both installed at the same time, that is if gcc can be changed to allow crt=clib3? (not a huge thing you might disregard it altogether). But great work on getting NCurses over to the AmigaOS4, I was looking at it just a couple of weeks ago, good timing!!!
This would require the compiler suites to be changed. IMHO, it makes more sense to keep the original clib2 and name this new one clib2-ts instead, replacing the old clib2-ts which probably not many people use or have installed. The bonus being that the compilers (even going back to GCC 4), support -mcrt=clib2-ts already. That said, there may be an issue in that clib2 and clib2-ts share the same headers (but have different link libs).
They aren't standard function in any C library. We can't implement any function just because is used by some ports..
@Futaura There is no need to have two different clib2 installed. They share most of the code. Creating a new mcrt will be a solution if was simply to create a new gcc spec and add this library. And at moment it isn't.. So I'll stay with clib2 now. In a future we'll see
Edit: even the include files would be different and cause problems on normal clib2 library
IIRC, the whole reason clib2 and clib2-ts co-existed in the first place was so that single threaded applications did not have all the extra overhead (both in terms of speed and size) imposed on them unnecessarily.
yes but the include files was the same since they are shared by both libraries. My include files are totally different than original clib2. So you will have functions present in include files that are not present in clib2 lib (or contrary)