New verson of CLiB2 from Andrea (afxgroup)

@Andrea
I checked what version of bison i have: 3.0.4-1.. And yeah, checked cygwin repo, there i can see or 3.8.2-1 (current) or can rollback to 3.7.6-1.

Maybe that mean it's time to fix adtools repo about binutils ? I hope to update binutils very soon once finish with scummvm, so that bug should disappear, but in meantime we can fix it manually for make gcc builds.

If i remember right i have the same issue even with my 3.0.4-1 version of bison and it was just about fixing "plural.y" to be compatibe with newer bison.

If you will type in google "binutils/repo/intl/plural-exp.h:102:23: error: conflicting types for ‘libintl_gettextparse’; have ‘int(void)’" , there will be lots of reports about + workaround and patches. I can't say exactly what one i use through ..


EDIT: Oh i found in my install, that when i build gcc 11, i have plural.c, plural.y and plural-exp.h being +2 days difference of other files, so seems i change those ones. There they are:

https://kas1e.mikendezign.com/aos4/tmp/plural.c
https://kas1e.mikendezign.com/aos4/tmp/plural.y
https://kas1e.mikendezign.com/aos4/tmp/plural-exp.h

@Andrea
New fixes you commit yesterday deal with most of makefile issues, thanks! I go futher now, but stack with issues about "sysvipc" includes, so created ticket about.

@All
After all the latest changes and fixes, new clib2 now builds fine on cygwin (to directory you choose), not errors, everything going till end (we tested on gcc 8.4.0 and gcc 11.2) and co.


@joerg
Do you have maybe anyting interesting in your private clib2 builds, which you may want to share with us so we can include it to our new version ?

@kas1e

Since i'm only lurking (but that with great interest) i'd like to ask when a release for us mere mortals is due?

@Raziel
That question to Afxgroup :) I assume soon enough

Soon..

@afxgroup

...yay

@kas1e
Quote:I'm not even sure I still have any backups of my clib2.library implementation (it was incomplete anyway, and just a proof of concept that using a shared OS4 C library is no problem at all), but even it there are still backups of it on some of my DVD backups I currently don't have access to it.
My clib2.library implementation was obsolete as soon as the decision was made to use newlib instead for the shared OS4 C library. There were 2 main reasons for using newlib instead of clib2 for the shared OS4 C library:
1. Olsen was against using a shared C library and preferred using a static link C library instead.
2., maybe less important, but at that time newlib included much more functions. That may not be the case any more, at least not as huge differences as there were about 15-20 years ago when clib2 still was very limited.

The main reason implementing newlib.library was much easier than clib2.library was is that newlib supports shared versions (.so, .dll, etc.) on other OSes, while clib2 was created to only work as a static link library.

@joerg

well, if you find some spare time you can help the project :)
Of course this is addressed at anyone wants to help

Quote:For a new clib2.library I don't have the time.
Theoretically I could help implementing a new newlib4.library, based for example on sourceware.org/git/?p=newlib-cygwin.git;a=summary (adding even more incompatible interface versions to the initial newlib.library port makes less sense IMHO than creating an independent, and incompatible, newlib4.library instead) but that would be a bad idea. In order to clear all doubts it's something completely independent it should be done by someone else without access to the OS4 newlib.library sources instead.

but you don't have to create a new clib2 from scratch. You can work on that one we have created. And even the creation of clib2.library now is only planned but nothing else. Just fix and improve or implement new functions would be great. I've made really a lot of changes to the original clib2 code that something could be wrong now. I've tried to add examples once i have created something new but who knows..

@afxgroup
Quote:Currently I don't only have no time for anything like that, but no working AmigaOS 4.x system either.
I didn't check the current newlib sources, but the versions I used included several tests suits, especially for the errors in the soft float math parts of the library (all C libraries have errors in their soft float math implementations, functions with correct results would of course be possible as well, but way too slow to be usable, and much faster functions with slight errors are used instead).
Even if the tests in the newlib sources were build for testing newlib they should work for any C library, incl. clib2.

First beta released

https://github.com/afxgroup/clib2/releases/tag/v1.0.0-beta-1

Keep in mind that you can find some issues. Please test it with your projects and report them on github.

Create a copy of your existent clib2 before installing this (just in case..) and remove all existent include and libs

@afxgroup
issue #37: newlib.library (at least my versions, I don't know anything about newer ones) uses the clib2 low level I/O functions for the platform specific low level I/O functions.
IIRC the main reasons stdio in newlib was much faster, additionally to the better high level I/O functions, were using a different __BUFSIZ__ and much better getc()/putc() functions.
Additionally make sure async I/O can't be enabled for regular files, only for sockets.

I've made a lot of tests. even increasing __BUFSIZ__ doesn't help. I've compared the code but i don't see differences. Even adding Olaf's changes, while read speed is almost the same, write speed on char by char is reallt really slow.
There is a benchmark on test programs folder than on newlib tooks 8 seconds and on clib2 tooks 33 seconds on sam 440..

@afxgroup
Quote:The clib2 __BUFSIZ__ was too large, not too small.

Quote:I don't remember what clib2 did wrong, but the following should be the relevant part of newlib (from stdio.h, but I'm not sure if that's the internal stdio.h, or the public stdio.h for users, in newlib different includes are used for building and using the library):

with BUFSIZ of 1024 (newlib one)

i have clib2:

all at once: 0.260000
fwrite one byte at time: 18.300000
fputc one byte at time: 17.220000

newlib:

all at once: 0.330000
fwrite one byte at time: 4.340000
fputc one byte at time: 5.180000

with BUFSIZ of 8192 i have on clib2:

all at once: 0.240000
fwrite one byte at time: 17.680000
fputc one byte at time: 16.640000

So no great difference. So i don't think BUFSIZ is the problem

I've noticed that newlib doesn't add many checks that clib2 has. Maybe is that one the problem. Because for example there was a test on fwrite called twice that was doubling the time in the benchmark

And putc on clib2 use a similar macro to put the char in the buffer and doesn't do I/O except when the buffer is full

new beta version trunk has (thanks to debug..):

all at once 0.080000
fwrite one byte at time: 8.500000
fputc one byte at time: 7.240000

So not fast as newlib but faster.. :)

I have to try different buffer size but now i'm on right path

One more general question: what is the purpose of this clib2 implementation? Will it be merged into the official clib2 project?

Will new clib2 present in next OS4 SDK?