GNU bug report logs - #79995
31.0.50; Undefined reference to streq when CFLAGS are specified on a Windows build

Previous Next

To reply to this bug, email your comments to 79995 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Przemyslaw Kryger" <pkryger <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; Undefined reference to streq when CFLAGS are specified on
 a Windows build
Date: Fri, 12 Dec 2025 14:58:18 +0000

[Message part 1 (text/plain, inline)]

When I call configure with the following arguments:

  ./configure --without-native-compilation \
              --with-modules               \
              --with-gnutls                \
              CFLAGS='-O0 -g3'

then the subsequent make fails with diagnostics to undefined refernces
to `streq'.

Calling configure without CFLAGS results in a passing build, that is
when I call:

  ./configure --without-native-compilation \
              --with-modules               \
              --with-gnutls                

followed by make produces a working Emacs executable (the one I use to
submit this bug report).

Attached please find config.status, config.log, and config.out. The
latter is an output captured from the configure call that results with
failing build.

[config.log (text/plain, attachment)]

[config.out (text/plain, attachment)]

[config.status (text/plain, attachment)]

[Message part 5 (text/plain, inline)]

In GNU Emacs 31.0.50 (build 2, x86_64-w64-mingw32) of 2025-12-12 built
 on runnervm8j6r3
Repository revision: 0f3947b379d650883f811377729e89cb05f87ee0
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.26100
System Description: Microsoft Windows Server 2025 Datacenter (v10.0.2009.26100.7171)

Configured using:
 'configure --without-native-compilation --with-modules --with-gnutls'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LIBXML2 MODULES NOTIFY W32NOTIFY
PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-nonselected-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug lisp-mnt message mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils term/w32console rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel touch-screen dos-w32 ls-lisp
term/w32-nt disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
w32notify w32 multi-tty move-toolbar make-network-process
tty-child-frames emacs)

Memory information:
((conses 16 35201 20894) (symbols 48 5461 0) (strings 32 12360 1838)
 (string-bytes 1 312794) (vectors 16 5438) (vector-slots 8 58248 9590)
 (floats 8 21 610) (intervals 56 249 0) (buffers 1064 11))

Message #8 received at 79995 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Przemyslaw Kryger" <pkryger <at> gmail.com>
Cc: 79995 <at> debbugs.gnu.org
Subject: Re: bug#79995: 31.0.50;
 Undefined reference to streq when CFLAGS are specified on a Windows
 build
Date: Fri, 12 Dec 2025 17:28:47 +0200

> From: "Przemyslaw Kryger" <pkryger <at> gmail.com>
> Date: Fri, 12 Dec 2025 14:58:18 +0000
> 
> When I call configure with the following arguments:
> 
>   ./configure --without-native-compilation \
>               --with-modules               \
>               --with-gnutls                \
>               CFLAGS='-O0 -g3'
> 
> then the subsequent make fails with diagnostics to undefined refernces
> to `streq'.

I do this all the time, and never saw this problem.  Except that I
specify CFLAGS at the beginning of the command line, like this:

  CFLAGS='-O0 -g3' ./configure --without-native-compilation ...

The Emacs sources don't use streq, it is used by Gnulib functions.

> Attached please find config.status, config.log, and config.out. The
> latter is an output captured from the configure call that results with
> failing build.

You haven't included the moist important part of the problem: the
linker error message that failed the build.  I see nothing strange in
the files you posted: the configure script is indeed expected to
detect that the function streq is missing on MS-Windows, and use the
Gnulib replacement (in lib/string.h).  The linker error message is
important to understand why the build failed in your case.

Is this the first time you build Emacs on Windows?  If not, can you
try to describe what changed on your system since the last time you
built Emacs?  Was something updated or reinstalled, for example?

> In GNU Emacs 31.0.50 (build 2, x86_64-w64-mingw32) of 2025-12-12 built
>  on runnervm8j6r3
> Repository revision: 0f3947b379d650883f811377729e89cb05f87ee0

This version is a bit old.  Could you try with the latest master
branch, perhaps?  maybe there was some problem that was meanwhile
fixed.

Message #11 received at 79995 <at> debbugs.gnu.org (full text, mbox):

From: Przemysław Kryger <pkryger <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79995 <at> debbugs.gnu.org
Subject: Re: bug#79995: 31.0.50; Undefined reference to streq when CFLAGS
 are specified on a Windows build
Date: Fri, 12 Dec 2025 17:08:06 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: "Przemyslaw Kryger" <pkryger <at> gmail.com>
>> Date: Fri, 12 Dec 2025 14:58:18 +0000
>>
>> When I call configure with the following arguments:
>>
>>   ./configure --without-native-compilation \
>>               --with-modules               \
>>               --with-gnutls                \
>>               CFLAGS='-O0 -g3'
>>
>> then the subsequent make fails with diagnostics to undefined refernces
>> to `streq'.
>
> I do this all the time, and never saw this problem.  Except that I
> specify CFLAGS at the beginning of the command line, like this:
>
>   CFLAGS='-O0 -g3' ./configure --without-native-compilation ...

I took the 'pass CFLAGS as an argument' from nt/INSTALL which in line
466 says:

  A few frequently used options are needed when you want to produce an
  unoptimized binary with runtime checks enabled:

     ./configure --prefix=PREFIX --enable-checking='yes,glyphs' \
       CFLAGS='-O0 -g3'

I have run as you suggested, putting the CFLAGS in the beginning of the
command, but the result is the same, i.e. the linker emits diagnostics
for undefined references for `streq'.

> The Emacs sources don't use streq, it is used by Gnulib functions.

It's lib-src/ebrowse.c and lib-src/etags.c that are failing.

>> Attached please find config.status, config.log, and config.out. The
>> latter is an output captured from the configure call that results with
>> failing build.
>
> You haven't included the moist important part of the problem: the
> linker error message that failed the build.  I see nothing strange in
> the files you posted: the configure script is indeed expected to
> detect that the function streq is missing on MS-Windows, and use the
> Gnulib replacement (in lib/string.h).

I can see that configure is detetecting missing function.  At least this
is what I got from:

  checking whether streq is declared... no
  checking whether memeq is declared... no

>                                        The linker error message is
> important to understand why the build failed in your case.

I meant to include it, but for some reason I forgot! Sorry about
that.  Attached is the output from make.

[make.out (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

> Is this the first time you build Emacs on Windows?  If not, can you
> try to describe what changed on your system since the last time you
> built Emacs?  Was something updated or reinstalled, for example?

I am building Emacs on a remote machine in a GitHub runner [1]. So every
time the MSYS2/MinGW packages are installed anew.  Yet on the same
environment I can build successfully when not specifying CFLAGS.  What I
do is after a failure I log in to the container and run configure
without CFLAGS followed by make which completes successfully.  When I
subsequently call configure with CFLAGS specified the following make fails.

What I meant by that, is that even if something changes between spinning
a new container, the issue persists withing the one container.

[1] https://github.com/pkryger/setup-emacs-dev/

>> In GNU Emacs 31.0.50 (build 2, x86_64-w64-mingw32) of 2025-12-12 built
>>  on runnervm8j6r3
>> Repository revision: 0f3947b379d650883f811377729e89cb05f87ee0
>
> This version is a bit old.  Could you try with the latest master
> branch, perhaps?  maybe there was some problem that was meanwhile
> fixed.

I have just retried on 74cbef7c45f2cbff99679ef54656ba369b049f71, the
failure is exactly the same.

Message #14 received at 79995 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Przemysław Kryger <pkryger <at> gmail.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 79995 <at> debbugs.gnu.org
Subject: Re: bug#79995: 31.0.50; Undefined reference to streq when CFLAGS
 are specified on a Windows build
Date: Fri, 12 Dec 2025 20:29:57 +0200

> From: Przemysław Kryger <pkryger <at> gmail.com>
> Cc: 79995 <at> debbugs.gnu.org
> Date: Fri, 12 Dec 2025 17:08:06 +0000
> 
>   C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccI3phHK.o: in function `main':
>   D:/a/setup-emacs-dev/setup-emacs-dev/emacs/lib-src/etags.c:1329:(.text+0xea0): undefined reference to `streq'

Thius means that somehow Gnulib's string.c is being miscompiled,
because that's where streq should be.  It could be that the problem is
related to this:

>   string.c:19:9: warning: '_GL_STRING_INLINE' redefined
>      19 | #define _GL_STRING_INLINE _GL_EXTERN_INLINE
>         |         ^~~~~~~~~~~~~~~~~
>   In file included from C:/msys64/mingw64/include/io.h:10,
>                    from C:/msys64/mingw64/include/direct.h:10,
>                    from D:/a/setup-emacs-dev/setup-emacs-dev/emacs/nt/inc/ms-w32.h:304,
>                    from ../src/conf_post.h:38,
>                    from ../src/config.h:3833,
>                    from string.c:17:
>   ./string.h:87:10: note: this is the location of the previous definition
>      87 | # define _GL_STRING_INLINE _GL_INLINE
>         |          ^~~~~~~~~~~~~~~~~
>     CC       time_r.o

Although I don't quite see how this could cause the problem; maybe
Paul (CC'ed) does.

(Paul, I thing string.c should #undef _GL_STRING_INLINE before it
defines it, because system headers could include string.h before this
definition.  In this case, MinGW64's io.h includes string.h.)

Please show the output of the following command on the system where
you have this problem:

  nm -A lib/libgnu.a | fgrep streq

> > Is this the first time you build Emacs on Windows?  If not, can you
> > try to describe what changed on your system since the last time you
> > built Emacs?  Was something updated or reinstalled, for example?
> 
> I am building Emacs on a remote machine in a GitHub runner [1].

Sorry, I don't know what that means, and don't understand how that
affects the build.  We support local MinGW builds using the procedure
described in nt/INSTALL.W64.  Maybe the "GitHub runner", whatever that
is, changes how the build works or something.

Can someone who uses MinGW64 please try building with -O0 and report
if the build indeed fails due to streq?

Message #17 received at 79995 <at> debbugs.gnu.org (full text, mbox):

From: Przemysław Kryger <pkryger <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79995 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#79995: 31.0.50; Undefined reference to streq when CFLAGS
 are specified on a Windows build
Date: Fri, 12 Dec 2025 22:34:42 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Przemysław Kryger <pkryger <at> gmail.com>
>> Cc: 79995 <at> debbugs.gnu.org
>> Date: Fri, 12 Dec 2025 17:08:06 +0000
>> 
>>   C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccI3phHK.o: in function `main':
>>   D:/a/setup-emacs-dev/setup-emacs-dev/emacs/lib-src/etags.c:1329:(.text+0xea0): undefined reference to `streq'
>
> Thius means that somehow Gnulib's string.c is being miscompiled,
> because that's where streq should be.  It could be that the problem is
> related to this:
>
>>   string.c:19:9: warning: '_GL_STRING_INLINE' redefined
>>      19 | #define _GL_STRING_INLINE _GL_EXTERN_INLINE
>>         |         ^~~~~~~~~~~~~~~~~
>>   In file included from C:/msys64/mingw64/include/io.h:10,
>>                    from C:/msys64/mingw64/include/direct.h:10,
>>                    from D:/a/setup-emacs-dev/setup-emacs-dev/emacs/nt/inc/ms-w32.h:304,
>>                    from ../src/conf_post.h:38,
>>                    from ../src/config.h:3833,
>>                    from string.c:17:
>>   ./string.h:87:10: note: this is the location of the previous definition
>>      87 | # define _GL_STRING_INLINE _GL_INLINE
>>         |          ^~~~~~~~~~~~~~~~~
>>     CC       time_r.o
>
> Although I don't quite see how this could cause the problem; maybe
> Paul (CC'ed) does.

Exactly the same warning appears on a successful build, i.e., when I
don't specify CFLAGS.  Given that I would doubt it is a culprit, but not
completely preclude that.

[...]
> Please show the output of the following command on the system where
> you have this problem:
>
>   nm -A lib/libgnu.a | fgrep streq

After a failed build the output is:

  # nm -A lib/libgnu.a | fgrep streq
  lib/libgnu.a:sig2str.o:                 U streq
  lib/libgnu.a:time_rz.o:                 U streq

>> > Is this the first time you build Emacs on Windows?  If not, can you
>> > try to describe what changed on your system since the last time you
>> > built Emacs?  Was something updated or reinstalled, for example?
>> 
>> I am building Emacs on a remote machine in a GitHub runner [1].
>
> Sorry, I don't know what that means, and don't understand how that
> affects the build.
[...]

GitHub provides a reference [1].  On top of that I install MSYS2 [2],
and install a few libraries and tools to build Emacs [3].

[1] https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md
[2] https://github.com/marketplace/actions/setup-msys2
[3] https://github.com/pkryger/setup-emacs-dev/blob/2464fd4/action.yml#L110-L137

>                               Maybe the "GitHub runner", whatever that
> is, changes how the build works or something.
It is certainly possible.  I'd appreciate any pointers how I can debug
it deeper.

Message #20 received at 79995 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79995 <at> debbugs.gnu.org,
 Przemysław Kryger <pkryger <at> gmail.com>
Subject: Re: bug#79995: 31.0.50; Undefined reference to streq when CFLAGS are
 specified on a Windows build
Date: Fri, 12 Dec 2025 16:31:53 -0800

On 2025-12-12 10:29, Eli Zaretskii wrote:
>> From: Przemysław Kryger<pkryger <at> gmail.com>
>> Cc:79995 <at> debbugs.gnu.org
>> Date: Fri, 12 Dec 2025 17:08:06 +0000
>>
>>    C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\tmp\ccI3phHK.o: in function `main':
>>    D:/a/setup-emacs-dev/setup-emacs-dev/emacs/lib-src/etags.c:1329:(.text+0xea0): undefined reference to `streq'
> Thius means that somehow Gnulib's string.c is being miscompiled,
> because that's where streq should be.

I think I see the problem. It comes from two iffy practices and one 
understandable one:

1. On WINDOWSNT platforms, Emacs's src/conf_post.h includes <ms-w32.h> 
(after a comment saying this is iffy but fixing it would take some 
work...), and Emacs's nt/inc/ms-w32.h includes <direct.h> which on this 
platform includes <io.h> which in turn includes <string.h>.

2. Because Gnulib's lib/string.c includes <config.h> before it #defines 
_GL_STRING_INLINE, that #define is too late - config.h already included 
<string.h> so <string.h> already defaulted to the wrong value of 
_GL_STRING_INLINE, which means lib/string.h does not compile machine 
code for streq.

3. When you compile the rest of Emacs with -O0, the compiler uses the 
external definition of streq - which doesn't exist due to (1) and (2). 
This is understandable, and it's also understandable why the problem 
occurs on GCC only with -O0.

I just now fixed (2) on master by changing Gnulib's lib/string.h to 
define _GL_STRING_INLINE before including <config.h>, and updating Emacs 
master to current Gnulib. Please give it a try.

As I recall we've had issues with (1) before now, and it's likely we'll 
have issues with (1) in the future. It would be nice if a Microsoft 
Windows expert could move iffy #include directives out of <config.h> and 
its includees, or at least have the iffy includes happen only if needed.

Message #23 received at 79995 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Przemysław Kryger <pkryger <at> gmail.com>
Cc: 79995 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#79995: 31.0.50; Undefined reference to streq when CFLAGS
 are specified on a Windows build
Date: Sat, 13 Dec 2025 09:49:59 +0200

> From: Przemysław Kryger <pkryger <at> gmail.com>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  79995 <at> debbugs.gnu.org
> Date: Fri, 12 Dec 2025 22:34:42 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Please show the output of the following command on the system where
> > you have this problem:
> >
> >   nm -A lib/libgnu.a | fgrep streq
> 
> After a failed build the output is:
> 
>   # nm -A lib/libgnu.a | fgrep streq
>   lib/libgnu.a:sig2str.o:                 U streq
>   lib/libgnu.a:time_rz.o:                 U streq

That explains the problem: there's no streq in libgnu.a.  I think Paul
explained why this happens.  Please try the current master branch.

Message #26 received at 79995 <at> debbugs.gnu.org (full text, mbox):

From: Przemysław Kryger <pkryger <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79995 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#79995: 31.0.50; Undefined reference to streq when CFLAGS
 are specified on a Windows build
Date: Sat, 13 Dec 2025 08:50:09 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Przemysław Kryger <pkryger <at> gmail.com>
>> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  79995 <at> debbugs.gnu.org
>> Date: Fri, 12 Dec 2025 22:34:42 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Please show the output of the following command on the system where
>> > you have this problem:
>> >
>> >   nm -A lib/libgnu.a | fgrep streq
>> 
>> After a failed build the output is:
>> 
>>   # nm -A lib/libgnu.a | fgrep streq
>>   lib/libgnu.a:sig2str.o:                 U streq
>>   lib/libgnu.a:time_rz.o:                 U streq
>
> That explains the problem: there's no streq in libgnu.a.  I think Paul
> explained why this happens.  Please try the current master branch.

I have build it successfully on 41ffeaec15b9a0f052de2d2e5eab23302c4ce46b
(the latest Paul's commit).  Thank you for your help!

Message #31 received at 79995-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Przemysław Kryger <pkryger <at> gmail.com>
Cc: 79995-done <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#79995: 31.0.50; Undefined reference to streq when CFLAGS
 are specified on a Windows build
Date: Sat, 13 Dec 2025 11:32:33 +0200

> From: Przemysław Kryger <pkryger <at> gmail.com>
> Cc: eggert <at> cs.ucla.edu,  79995 <at> debbugs.gnu.org
> Date: Sat, 13 Dec 2025 08:50:09 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Przemysław Kryger <pkryger <at> gmail.com>
> >> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  79995 <at> debbugs.gnu.org
> >> Date: Fri, 12 Dec 2025 22:34:42 +0000
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> > Please show the output of the following command on the system where
> >> > you have this problem:
> >> >
> >> >   nm -A lib/libgnu.a | fgrep streq
> >> 
> >> After a failed build the output is:
> >> 
> >>   # nm -A lib/libgnu.a | fgrep streq
> >>   lib/libgnu.a:sig2str.o:                 U streq
> >>   lib/libgnu.a:time_rz.o:                 U streq
> >
> > That explains the problem: there's no streq in libgnu.a.  I think Paul
> > explained why this happens.  Please try the current master branch.
> 
> I have build it successfully on 41ffeaec15b9a0f052de2d2e5eab23302c4ce46b
> (the latest Paul's commit).  Thank you for your help!

Thanks, I'm therefore closing this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.