bug-gnulib
[Top][All Lists]
Advanced

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

Re: module libposix


From: Bruno Haible
Subject: Re: module libposix
Date: Fri, 17 Sep 2010 00:16:00 +0200
User-agent: KMail/1.9.9

Hi Bruce,

> Methinks the idea here would be to install system replacements into the 
> include
> directory IFF these replacements did something useful.  Perhaps I can fiddle
> the installation sequence so a script parses everything.in.h to see if
> the @HAVE-s
> got replaced with 1's or 0's.

In the beginning, gnulib's .h replacements were designed like that. Until we
noticed that the burden to keep the condition up-to-date was growing, and that
creating an unneeded .h file did not harm.

> The final result should be that libposix client projects would place:
>    -I$(prefix)/include/gnulib
> in their CFLAGS.

As you like.

> >>   AC_CHECK_LIBPOSIX([2010.09.16],
> >>     AC_MSG_ERROR([libposix is too old or not installed]))
> >
> > Yes, I agree with the idea. Of course this macro should use the 'havelib'
> > module (so that --with-* options are offered and -rpath flags are handled
> > automatically).
> 
> if the lib gets built as an object archive, then -rpath would not be needed.
> One would hope that this library would be tiny enough so as not to be
> worth the bother of making it a shared object...... :-D

Whether tiny or big - a library in .a format with non-PIC objects cannot be used
as a dependency when building shared libraries (except on Linux/x86, due to
particular behaviour of GNU ld). And libraries in .a format with PIC objects
cannot easily be created with libtool (since libtool supports only non-PIC .a
and PIC .so). For this reason, libraries meant for general use should NEVER
be installed with --disable-shared.

Bruno



reply via email to

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