bug-gnulib
[Top][All Lists]
Advanced

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

Re: gnulib request


From: Sean Boudreau
Subject: Re: gnulib request
Date: Mon, 1 Oct 2007 09:49:06 -0400
User-agent: Mutt/1.4.2.3i

On Sun, Sep 30, 2007 at 06:51:04PM -0400, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to Sean Boudreau on 9/30/2007 4:10 PM:
> > Hello:
> 
> Hello Sean, and adding bug-gnulib,
> 
> > 
> > Would it be possible to not bring in freading.c and fpurge.c
> > and to disable the associated tests if fflush() behaves as
> > you expect?
> 
> For m4 1.4.x: If fflush completely obeys POSIX (note that even glibc has
> bugs here, when it comes to properly flushing at program exit), then
> freading.c and fpurge.c might still be compiled because of the
> configure-time tests for those modules, but they will not be linked into
> the final m4 executable because their symbols are not directly
> referenced
> from the main body of m4 source code - that is one of the properties of
> a
> static library.  Compiling them as part of libgnu.a is therefore a
> slight
> waste of time, but otherwise harmless.
> 
> Now for m4 2.0, which uses dynamic libraries, you are correct that the
> final dynamic library will therefore be slightly bloated by the addition
> of symbols for freading and fpurge, even though nothing in the rest of
> the
> library or the main program uses it.  But I don't know if anything can
> be
> done (or is worth doing) to avoid that.

The issue is with their compilation.  They're non standard
and present challenges in the portability department so if
they aren't needed the less they're referenced the better.
I'm not sure this is an actual gnulib issue as presumeably
someone could use freading(), fpurge() independently of
fflush() (although I wouldn't recommend it).

Thanks for your time.

-seanb




reply via email to

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