Hyperion Entertainment Message Boards

Since the new clib2 from OS4Depot doesn't contain a libauto.a, I decided to created my own libauto.a. The idltool utility creates a 'main.c' file and a 'base.c' file for each XML file in SDK:Include/interfaces. Since the main.c files check if the library is opened and open the library if not already opened, is there any reason to compile the base.c files (which only open the library) into a libauto.a??

Compiling filesysbox for clib2 libauto.a fails because the 'statvfs.h' file is missing from the clib2 includes. Is it OK to copy the statvfs.h file from the newlib includes to the clib2 includes??

I would not recommend trying to make filesysbox based file systems using clib2.

Filesysbox.library is compiled using newlib typedefs, defines and structure and if some of these are different in clib2 then it can cause problems if you use clib2.

One such problem is that uid_t/gid_t are 16-bit in newlib but are 32-bit in clib2. As a result when using clib2 the fbx_stat structure as defined in <libraries/filesysbox.h> will have a different size and be incompatible with the one expected by the library.

This particular issue is "fixed" in the latest beta version by using new fbx_uid_t/fbx_gid_t typedefs instead of uid_t/gid_t but there might be other similar problems that have not been found because no testing has been made with clib2 so far and compatibility with clib2 is not a priority for me.

The reason for changing the uid_t/gid_t to fbx_uid_t/fbx_gid_t is BTW not for compatibility with clib2 but to allow support for 32-bit user and group IDs in filesysbox (this extension is done in a way so that it doesn't break compatibility with existing file system binaries).

salass00 wrote:I would not recommend trying to make filesysbox based file systems using clib2.

O.K. Thanks for the information. Further investigation has also answered my question about excluding the 'base.c' files from a libauto.a compile. It seems that the library bases are declared in the 'base.c' files and declared as 'extern' in the 'main.c' files, which I think means I would need to edit all the 'main.c' files if I don't include the 'base.c' files.

I've also found that there is no XML interface file for XadMaster library and had to create my own. I've also found that several autoinits produced from the XML interface files by ldltool (like application.library) don't include a main.c file. If you assume that ldltool will produce 'main.c' files from all the XML files, I think you could end up with a libauto.a that would open some libraries but not the interfaces for those libraries.

Thanks for the filesysbox explanation.

You can just copy over the libauto.a from the the existing SDK.

WRT to some missing xml files etc libauto.a does not and never did include all the libraries it was possible to open.

It's generally considered deprecated these days as there is insuffiecient control of library versioning etc.

(like application.library)

appliication.library doesn't have a "main" interface, you must open version 2 of the 'application' or 'prefs' interfaces. This is perfect example of why libauto is deprecated.

broadblues wrote:You can just copy over the libauto.a from the the existing SDK.

WRT to some missing xml files etc libauto.a does not and never did include all the libraries it was possible to open.

That's the reason I decided to create my own libauto.a.

It's generally considered deprecated these days as there is insuffiecient control of library versioning etc.

Said deprecation might be more convincing if some SDK documentation (SDK:Documentation/Developer Info/General/Migration Guide.pdf) didn't state that it's the preferred method and most of the examples in SDK:Examples/ didn't use libauto (-lauto). I personally find labauto.a useful for writing personal command utilities and testing new or modified code. However, it's probably not a good idea to publicly release source code that uses libauto.a (-lauto).

As far as library versioning goes, if I list all the LIBS: & Kickstart library versions, they are so inconsistant that I'm unsure what versions should be required. If you are going to release a program that will be specified to work, for example, with OS 4.1update6 and above; you will need a copy of that release to determine what version of each library to require in your program. I think all the library versions in each release should be the same and they should all have the versions bumped for a release (even those that are unchanged). I know that runs against the traditional rules for version changes, but it would simplify version requirements for a program.

appliication.library doesn't have a "main" interface, you must open version 2 of the 'application' or 'prefs' interfaces. This is perfect example of why libauto is deprecated.

As long as the XML files are kept up-to-date (application.library appears to be) my self created libauto works for me. I only mentioned that some libraries have no "main" interface is because my original makefile for compiling a libauto only compiled ..main.c and ..base.c files and I had to update the makefile.