[Top][All Lists]

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

Re: overriding glibc stub functions

From: Paul Eggert
Subject: Re: overriding glibc stub functions
Date: Sun, 23 Feb 2020 23:44:58 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 2/23/20 6:27 PM, Bruno Haible wrote:
Therefore I think we need to do two things:

   * For those functions that may be stubs in glibc, define HAVE_FUNC to 1
     instead of 0 if glibc implements it as a stub.

This sounds like it could lead to trouble, as it runs afoul of longstanding Autoconf tradition. Even within Gnulib, we'd have to investigate and probably rewrite code using HAVE_LCHMOD, HAVE_REVOKE, and perhaps other such symbols. And we'd also have to warn all downstream users that the HAVE_* tradition is changing (at least for glibc symbols), and downstream users would need to change their own code that uses HAVE_LCHMOD or whatever. And what about downstream code that uses AC_CHECK_FUNCS([lchmod]) or AC_CHECK_FUNCS([sigreturn]) already, and gets the longstanding Autoconf interpretation for symbols it checks directly? Won't this make things too confusing?

Perhaps it would be better to use HAVE_LCHMOD=0 and REPLACE_LCHMOD=1 in this problematic situation, i.e., to bring back the REPLACE_LCHMOD code without altering HAVE_LCHMOD. This would be less likely to break other uses, because it would not conflict with the Autoconf tradition.

  * Reinstall (at least partially) the code for REPLACE_LCHMOD=1.

Yes, it sounds like we'll need to do that to support static linking and -lc.

reply via email to

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