bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Gavin Smith <gavinsmith0123@gmail.com>
To: bug-gnulib@gnu.org
Cc: bug-texinfo@gnu.org
Subject: Avoid gnulib redefinitions - MDA, free-posix
Date: Sat, 29 Oct 2022 14:36:13 +0100	[thread overview]
Message-ID: <Y10sTbYUvG3TKGbt@starmint> (raw)

Previously in the Texinfo project, we added variables to configure.ac to
stop the redefinition of "Microsoft deprecated aliases":

https://lists.gnu.org/archive/html/bug-gnulib/2021-03/msg00004.html

For example, GNULIB_MDA_FDOPEN to stop the redefinition of 'fdopen'.

Recently, it was reported that this didn't work when building on
MS-Windows.  I found that it should maybe be GL_GNULIB_MDA_FDOPEN instead:

https://lists.gnu.org/archive/html/bug-texinfo/2022-10/msg00180.html

I had identified the following change as potentially being responsible:

2021-04-11  Bruno Haible  <bruno@clisp.org>

        Support several gnulib-tool invocations under the same configure.ac.
        Reported by Reuben Thomas <rrt@sc3d.org> in
        <https://lists.gnu.org/archive/html/bug-gnulib/2021-04/msg00104.html>.  
        This is done by defining the Gnulib module indicator variables per
        gnulib-tool invocation. So that a generated .h file is no longer
        influenced by the set of modules used in other gnulib-tool invocations. 
        * gnulib-tool (func_compute_include_guard_prefix): Set
        module_indicator_prefix.

Should we use the variables with the GL_ prefix now and is this something
we can rely on?  Or should we simply #undef fdopen and the other symbols?

We don't use fdopen, putenv or mktemp in the library being built, but these
are pulled in by Gnulib dependencies.

I don't know if it is possible at all but it would seem to be better
for Gnulib not to redefine symbols that are not actually used in the
program.  I'd like to keep the use of Gnulib code to a minimum, only
using it where there is a significant portability benefit.

Likewise, there is a warning about the redefinition of "free", that
comes from the free-posix module.  The issue is, when building a
Perl extension module, some source files include Perl headers that
also redefine "free".

free-posix is to work around the possibility that free overwrites
the value of errno.  It's unlikely that this would cause a problem
in our code, but free-posix is required internally by Gnulib code.

It seems undesirable to override such a simple function as 'free',
when this is not something the user has asked for - as in our case,
it caused a conflict with other uses (Perl headers).

This may be hard for you to change, though.  Here is one idea.  When
using a module like 'free-posix', if it is loaded as a dependency only,
use the redefinition in Gnulib code only, but do not override symbols
in user code.  It would be as if there were two modules, say
gl-free-posix and free-posix, where gl-free-posix made the redefinition
of rpl_gl_free and free-posix (requested by the user) redirected rpl_free
to rpl_gl_free.


             reply	other threads:[~2022-10-29 13:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-29 13:36 Gavin Smith [this message]
2022-10-29 16:58 ` Avoid gnulib redefinitions - MDA, free-posix Paul Eggert
2022-10-29 18:53   ` Gavin Smith
2022-10-30 13:37     ` Avoid gnulib redefinitions - free-posix Bruno Haible
2022-10-29 21:48 ` Avoid gnulib redefinitions - MDA Bruno Haible
2022-10-29 21:59   ` Gavin Smith
2022-10-29 22:09     ` Bruno Haible
2022-10-29 22:20       ` Gavin Smith

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  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=Y10sTbYUvG3TKGbt@starmint \
    --to=gavinsmith0123@gmail.com \
    --cc=bug-gnulib@gnu.org \
    --cc=bug-texinfo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).