Hi Bruno, > IMO the unit tests should be included. IMO also, the unit tests should be included.
> IMO the inclusion guards of the headers need to be transformed IMO, I don't know that. If a confused program winds up including both, then you'll have duplicate definitions. Theoretically, the contents of libposix and what you get from gnulib would be the same. As noted elsewhere, projects that use non-posix modules from gnulib ought to be getting the libposix dependent modules via libposix. I think the libposix and gnulib guards should guard against including each other as well as guarding against multiple self inclusion. > 2) The library should use libtool versioning: > > # Libtool's library version information for libposix. > # See the libtool documentation, section "Library interface versions". > LTV_CURRENT=0 > LTV_REVISION=0 > LTV_AGE=0 > libposix_la_LDFLAGS += -version-info $(LTV_CURRENT):$(LTV_REVISION):$(LTV_AGE) Then it may as well be: libposix_la_LDFLAGS += -version-info 0:0:0 because the only other rational choice is going to be a version that changes daily whether or not there are changes to the interface. Just hard code to 0:0:0 -- with comments about why. > Undefined symbols: > "_program_name", referenced from: > _program_name$non_lazy_ptr in error.o > ld: symbol(s) not found > collect2: ld returned 1 exit status > make[4]: *** [libposix.la] Error 1 > > I would suggest to fix this by adding the 'progname' module to the library. That means knowing that on one platform, there is a POSIX module that depends upon a non-posix module. I would suggest either adding 'progname' to the list of posix modules (eeewww, ick), or decoupling the error module from progname. viz. remove the "extern" attribute from the error.c declaration and check it for NULL before use. Probably a good idea anyway. > ld: library not found for -lrt > Fix: Don't hardcode -lrt. Obviously. I think I hacked it in to get it working earlier on. > 5) The libposix.m4 file should be rewritten from scratch to *not* use > pkg-config and instead use the macros from the gnulib 'havelib' module. > 6) On Solaris 8, with gcc, the files fnmatch.h, float.h, errno.h, stddef.h, > stdbool.h, stdarg.h, sched.h get created after the library has been built, > with invalid contents (#include_next without argument, and such). The mistake > is that you have included stddef.h in nobase_nodist_pkginclude_HEADERS, > although STDDEF_H is empty on this platform. Yep, these are still hang-out items. It isn't obvious to me how to load the nobase_nodist_pkginclude_HEADERS macro, based on reading Makefile.am. Perhaps a post-install script that goes in and figures out which are not needed by grepping for empty include_next's. :) Or, configuring a script that detects empty HEADER_H substitutions and removes the related file. Equivalent, but a little less hacky. I am out of time for a little while. Maybe next weekend. Cheers - Bruce
