bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org, Paul Eggert <eggert@cs.ucla.edu>
Cc: Po Lu <luangruo@yahoo.com>
Subject: Re: API levels and functions on Android
Date: Thu, 19 Jan 2023 11:27:08 +0100	[thread overview]
Message-ID: <12251019.9WldNEQ4yK@nimes> (raw)
In-Reply-To: <33c38598-bedd-9ac9-f6c7-d2206de59260@cs.ucla.edu>

Paul Eggert wrote:
> > Defining REPLACE_GLOB=1 despite HAVE_GLOB=0 will be the way to make Gnulib
> > define 'rpl_glob' instead of 'glob', so that there is no conflict with libc.so.
> > 
> > I still need to work out the details how this would/will work. So as to
> > do things correctly on Android, while OTOH not adding lots of configure tests
> > for the other platforms...
> Thanks for looking into this.
> On Android, should we always define REPLACE_WHATEVER when 'whatever' 
> doesn't exist, at least for all the REPLACE_WHATEVER instances that 
> currently exist in Gnulib? After all, 'whatever' might exist in some 
> future Android version.

I think this would be overkill. Remember, for debuggability, when Gnulib
defines a function 'foo', we want gdb to know it by the name 'foo', if
there is no imperative to name it differently.

The two known imperatives are
  - call it 'rpl_foo', to avoid a clash with libc,
  - when shipping a shared library libgaga, call it 'libgaga_foo' or 'gaga_foo',
    to avoid a clash with other shared libraries.
If none of these two imperatives apply, the name 'foo' without any prefix is
the natural choice.

> Would it make sense to wait until you've worked out the details, before 
> installing patches like the REPLACE_UTIMENSAT=1 patch?

Yes, definitely.


  reply	other threads:[~2023-01-19 10:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87o7qw6jap.fsf.ref@yahoo.com>
2023-01-18 13:53 ` Follow up to last post Po Lu
2023-01-18 22:18   ` Paul Eggert
2023-01-18 23:23     ` API levels and functions on Android Bruno Haible
2023-01-19  4:24       ` Paul Eggert
2023-01-19 10:27         ` Bruno Haible [this message]
2023-01-19  0:44     ` Follow up to last post Po Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12251019.9WldNEQ4yK@nimes \
    --to=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=luangruo@yahoo.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).