Re: texinfo-7.2.92 pretest available

[Eli Zaretskii]

> From: Bruno Haible <br...@clisp.org>
> Cc: pertu...@free.fr, gavinsmith0...@gmail.com, bug-texinfo@gnu.org
> Date: Sun, 22 Feb 2026 15:36:54 +0100
> 
> Suggestion 1:
>   In which EXE or DLL is each located? The one in main surely is in
>   ctexi2any.exe.

Are you sure?  When I step with GDB in the 'main' function, which is
in ctexi2any.exe, I see this:

  (gdb) info variables optarg
  All variables matching regular expression "optarg":

  File getopt.c:
  89:     char *rpl_optarg;

  Non-debugging symbols:
  0x00d64390  _imp__rpl_optarg
  0x00d64698  _nm__rpl_optarg

Doesn't that mean rpl_optarg is in getopt.c?

Also, rpl_getopt_long that is known to 'main' is described as residing
in the .exe:

  (gdb) info symbol rpl_getopt_internal
  rpl_getopt_internal in section .text of 
d:\gnu\texinfo-7.2.92-C\tta\C\.libs\ctexi2any.exe

However, if I step into getopt_internal, when it is called by 'main',
I see something different:

  (gdb) info symbol rpl_getopt_internal
  rpl_getopt_internal in section .text of 
d:\gnu\texinfo-7.2.92-C\tta\C\.libs\libtexinfo-main-0.dll

How can this be?  The 'main' function calls rpl_getopt_internal, which
it thinks is in the .exe, but actually winds up in a DLL?

>   Where does the other one, referenced by rpl_getopt_long,
>   reside? I.e. is rpl_getopt_long compiled into the executable or some DLL?

You tell me, given the above.

>   If it is compiled into a DLL, the declaration of 'optarg' needs to be
>   changed from
>     char *optarg;
>   to
>     LIBFOO_DLL_VARIABLE char *optarg;
>   where LIBFOO_DLL_VARIABLE needs to expand to
>     __declspec(dllexport)
>   or
>     __declspec(dllimport)
>   depending on the compilation unit.
> 
>   This is the approach chosen by GNU gettext, which has a copy of
>   rpl_getopt_long in its libgettextlib DLL. It uses a local modification
>   of the Gnulib 'getopt' module:
>   
> https://gitweb.git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gnulib-local/lib/getopt-core.h.diff;h=5e385cf7d32f66cad47d11785038441539521505;hb=HEAD

So the way to resolve this is to modify a Gnulib module?  The
declaration of optarg is in the Gnulib header getopt-core.h.

> Suggestion 2:
>   What other options are contained in perl_conf_CFLAGS and perl_conf_LDFLAGS?

  perl_conf_CFLAGS: -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE 
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv 
-fno-strict-aliasing -mms-bitfields

  perl_conf_LIB_CFLAGS: -DWIN32 -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE 
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv 
-fno-strict-aliasing -mms-bitfields  

  perl_conf_LIB_LDFLAGS: -static-libgcc -static-libstdc++ 
-L"D:/usr/Perl/lib/CORE" -L"C:/MinGW/i686-w64-mingw32/lib" -no-undefined

> Suggestion 3 (from ChatGPT):
>   Are some compilation units compiled with /MT and others with /MD ?

These are MSVC options, not GCC options.  The GCC equivalent of /MT is
not used and the equivalent of /MD is default behavior on
MinGW, AFAIU.

> > But then this Gnulib
> > trick with renaming was explicitly meant to avoid messing with the
> > system's getopt, so I'd expect that to work in my case.
> 
> Yes, rpl_optarg is intentionally meant to be different from the mingw
> optarg.

Then I'm surprised to hear that Gettext needed to hack around that.
I'd expect this to work with MinGW.

Thanks.