Just wondering, doesn't each compiler (sasc, vbcc, gcc) come with a ready-to-use libc? What's the advantage of this new libc project?
Long story. This clib2 'C' runtime library grew out of the need to port Samba cleanly to the Amiga. My first attempts to port Samba would use SAS/C, and a clever collection of preprocessor tricks to fool the Samba code into working with the SAS/C runtime library and the socket I/O I had grafted onto it. All this would have been much easier if SAS, Inc. had made the library source code available, as Manx, Inc. had done for their Aztec 'C' compiler. Later Samba versions did not port using the same tricks, so I had to find a way to make it work, and extending an existing library was out of the question.
So, this is how clib2 came to be. The complete source code is available so that you can extend it or review it (not all other 'C' runtime libraries for Amiga compilers are open sourced). clib2 offers features which you cannot find in other runtime libraries, such as low level interfaces for changing the library's behaviour. clib2 also intends to support more than just ANSI 'C' (SAS/C is, for example, stuck with the old 1991 standard), in that it implements almost everything in ISO 'C' (1994) and much of C99. Some POSIX features are present as well, to help porting software packages like Samba. Finally, clib2 is free and available under a BSD-style license, which means that you can freely borrow code.
Olaf, thanks for the explanation and it makes good sense to write this library! Does this mean that I can link against this library and don't need to link against e.g. SASC libc any more? Does the '2' in clib2 stand for something like version 2 or what is the meaning of '2'? And I am bit lost in the number of different libc/posix libs implementations that are floating around (need to investigate a bit to get a clearer picture of what is there). If you or someone could sheer some light on the differences of versions and e.g. the relation to ixemul.library (e.g. why not use ixemul.library) then that would be great.
> Olaf, thanks for the explanation and it makes good sense to write this library! Does
> this mean that I can link against this library and don't need to link against e.g.
> SASC libc any more?
In theory, yes. I haven't updated the SAS/C build in a while, so linking would be a bit difficult, to say the least. The SAS/C build also lacks support for the small data model (the GCC version has support for it, though). The primary reason for having the SAS/C build was to aid in debugging, and beyond that it probably isn't useful for anything else.
> Does the '2' in clib2 stand for something like version 2 or what is the meaning of '2'?
When I started on this project, long before I registered it with sourceforge.net, I already had a "clib" directory in my own CVS repository. I only added the "2" to "clib2" to avoid a clash. But as these things go, the name stuck.
> why not use ixemul.library
I personally gave up on ixemul.library when code that used to run before stopped working: the maintainers had changed the API. Also, it became very annoying that you couldn't fix bugs or trace code execution in ixemul.library, because either ixtrace crashed, flooded you with information that didn't help, or you couldn't rebuild ixemul.library easily. clib2 was designed as a linker library because once you link against it, the library doesn't change. Also, you can modify parts of the library code to your liking, and not just for debugging.
As things stand, clib2 can do stuff other libraries were not designed to handle, and the other way round. What clib2 gives you is the freedom to change what you like (and to look at code that gives you trouble), and to change it easily. Just make your changes and rebuild using "make -f GNUmakefile.os4". Once you've added the netinclude directory from the OS4 SDK, everything should build right out of the box.