bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libposix - is it done yet?


From: Bruce Korb
Subject: Re: libposix - is it done yet?
Date: Sun, 10 Oct 2010 10:59:00 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Thunderbird/3.0.6

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]