bug-groff
[Top][All Lists]
Advanced

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

[bug #51554] [patch] add missing libgnu.a in *_LDADD in *.am


From: Ingo Schwarze
Subject: [bug #51554] [patch] add missing libgnu.a in *_LDADD in *.am
Date: Tue, 25 Jul 2017 09:37:42 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:54.0) Gecko/20100101 Firefox/54.0

Follow-up Comment #2, bug #51554 (project groff):

Hi Werner, thanks for having a look.  Your comment helped me to better
understand what is going on, but i think what you suggest in comment #1 misses
the point.

In https://savannah.gnu.org/bugs/?51330 , Bertrand added the gnulib
fprintf-posix module to the groff gnulib configuration.  If i understand
correctly, the intention of that change is to replace the native fprintf(3)
implementation of the operating system we are running on with the gnulib
implementation, if the configuration system comes to the conclusion that - for
whatever reason - it dislikes the native fprintf(3).  In that case, all
programs using fprintf(3) must link against gnulib, and that is what my patch
"libgnu.patch" does.

I think that Bertrand's patch committed in
https://savannah.gnu.org/bugs/?51330 cannot have been tested at all.  It
simply cannot build at all when the fprintf-posix check returns a negative
result.

This doesn't have anything to do with any of the following questions:

 - Whether gnulib improved anything in their detection or replacement code
since February.  (Anecdotically, adding --remote  to all the "git submodule
update" lines in bootstrap makes no difference, but that doesn't matter for
the question at hand.)

 - Whether gnulib tests for fprintf(3) are sensible or bogus, and whether the
gnulib implementation of fprintf(3) may be correct or buggy.

 - Whether the OpenBSD implementation of fprintf(3) is correct or  buggy.

These are also potentially interesting questions (especially the last one),
but they are unrelated to my patch.


All that said, i doubt the wisdom of replacing the fprintf(3) implementation
(no matter what the circumstances).  While there might be a theoretical reason
to do that, i cannot remember ever having seen a system in practice where that
is needed.  But again, whether or not we want to use gnulib fprintf-posix is a
separate question.  *IF* we want to use it, then each and every program using
fprintf(3) has to link against libgnu.a.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51554>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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