[Bug build/27657] New: GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom

[Bug build/27657] New: GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom

[chrisj at rtems dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27657

            Bug ID: 27657
           Summary: GDB fails to link on MSYS2 and mingw64 looking for
                    BCryptGenRandom
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: chrisj at rtems dot org
  Target Milestone: ---

I am building the RTEMS tool chain which includes GDB on Windows using MSYS2.
We build GDB with Python. I am getting an unresolved symbol error for
BCryptGenRandom. 

The build log is ..

https://ftp.rtems.org/pub/rtems/people/chrisj/gdb/rsb-log-20210328-155802.txt

The repo we clone is a mirror of yours on github ...

https://github.com/RTEMS/sourceware-mirror-binutils-gdb

The version we are using is sourceware-mirror-binutils-gdb-fc9b4c8.

GDB configure is in mixed minds about bcrypt.h ...

checking bcrypt.h presence... yes
configure: WARNING: bcrypt.h: present but cannot be compiled
configure: WARNING: bcrypt.h:     check for missing prerequisite headers?
configure: WARNING: bcrypt.h: see the Autoconf documentation
configure: WARNING: bcrypt.h:     section "Present But Cannot Be Compiled"
configure: WARNING: bcrypt.h: proceeding with the compiler's result
checking for bcrypt.h... no
checking whether the bcrypt library is guaranteed to be present... checking if
x86_64-w64-mingw32-gcc -O2 -g -pipe
-I/d/opt/rtems/rsb.git/rtems/build/tmp/sb-197609/6s/d/opt/rtems/6/include
supports -fno-rtti -fno-exceptions... checking if x86_64-w64-mingw32-gcc -O2 -g
-pipe -I/d/opt/rtems/rsb.git/rtems/build/tmp/sb-197609/6s/d/opt/rtems/6/include
supports -fno-rtti -fno-exceptions... no

The source builds without error which is nice but the link fails ...

  CXXLD  gdb.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
../gnulib/import/libgnu.a(getrandom.o): in function `getrandom':
D:\opt\rtems\rsb.git\rtems\build\srgfxwm1\build\gnulib\import/../../../sourceware-mirror-binutils-gdb-fc9b4c8/gnulib/import/getrandom.c:129:
undefined reference to `BCryptGenRandom'
collect2.exe: error: ld returned 1 exit status

>From my simplified outside view it seems like the library libbcrypt.a is
missing ...

$ grep -r BCryptGenRandom /mingw64
/mingw64/x86_64-w64-mingw32/include/bcrypt.h:  NTSTATUS WINAPI BCryptGenRandom
(BCRYPT_ALG_HANDLE hAlgorithm, PUCHAR pbBuffer, ULONG cbBuffer, ULONG dwFlags);
Binary file /mingw64/x86_64-w64-mingw32/lib/libbcrypt.a matches

The library is part of the MSYS2 package ...

$ pacman -Qo /mingw64/x86_64-w64-mingw32/lib/libbcrypt.a
/mingw64/x86_64-w64-mingw32/lib/libbcrypt.a is owned by
mingw-w64-x86_64-crt-git 9.0.0.6128.07922837-1

This looks like an archive wrapper for the standard Windows DLL.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/27657] GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom

[chrisj at rtems dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27657

--- Comment #1 from Chris Johns <chrisj at rtems dot org> ---
The gnulib config.log has this ...

configure:20640: checking bcrypt.h usability
configure:20640: x86_64-w64-mingw32-gcc -O2 -g -pipe
-I/d/opt/rtems/rsb.git/rtems/build/tmp/sb-197609/6s/d/opt/rtems/6/include -c -g
-O2 -D__USE_MINGW_ACCESS  conftest.c >&5
In file included from conftest.c:192:
C:/msys64/mingw64/x86_64-w64-mingw32/include/bcrypt.h:27:11: error: unknown
type name 'LONG'
   27 |   typedef LONG NTSTATUS,*PNTSTATUS;
      |           ^~~~
C:/msys64/mingw64/x86_64-w64-mingw32/include/bcrypt.h:174:5: error: unknown
type name 'ULONG'
  174 |     ULONG dwMinLength;
      |     ^~~~~
C:/msys64/mingw64/x86_64-w64-mingw32/include/bcrypt.h:175:5: error: unknown
type name 'ULONG'
  175 |     ULONG dwMaxLength;
      |     ^~~~~
C:/msys64/mingw64/x86_64-w64-mingw32/include/bcrypt.h:176:5: error: unknown
type name 'ULONG'
  176 |     ULONG dwIncrement;
      |     ^~~~~
C:/msys64/mingw64/x86_64-w64-mingw32/include/bcrypt.h:182:5: error: unknown
type name 'ULONG'

Should windows.h or something like that be included?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/27657] GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27657

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
I don't know the answer to this, but I'd suggest looking to see if
there are any reports of this problem to gnulib.
gdb doesn't actually use bcrypt.h at all, this is just pulled in
via gnulib for its getrandom module, AFAICT.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/27657] GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom

[cbiesinger at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27657

Christian Biesinger <cbiesinger at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cbiesinger at google dot com

--- Comment #3 from Christian Biesinger <cbiesinger at google dot com> ---
Hmm, something must be different on my system, I don't see this link error on
msys2...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/27657] GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom

[chrisj at rtems dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27657

--- Comment #4 from Chris Johns <chrisj at rtems dot org> ---
(In reply to Tom Tromey from comment #2)
> I don't know the answer to this, but I'd suggest looking to see if
> there are any reports of this problem to gnulib.

I fond nothing specifically related. There was some chat related to emacs a
year or so ago but I could not see anything specific.

> gdb doesn't actually use bcrypt.h at all, this is just pulled in
> via gnulib for its getrandom module, AFAICT.

Thanks. I think the reference is internal in the `tempfile` call or something
like that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/27657] GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom

[chrisj at rtems dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27657

--- Comment #5 from Chris Johns <chrisj at rtems dot org> ---
(In reply to Christian Biesinger from comment #3)
> Hmm, something must be different on my system, I don't see this link error
> on msys2...

Oh interesting and thanks. It is good to know it can be built. 

Is this a mingw gdb or an msys gdb?

We are building with:

 ../sourceware-mirror-binutils-gdb-fc9b4c8/configure --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=sparc-rtems6 --verbose --disable-nls
--disable-gas --disable-binutils --disable-ld --disable-gold --disable-gprof
--with-system-readline --without-included-gettext --disable-win32-registry
--disable-werror --disable-sim --without-zlib --with-expat --with-guile=no
--with-python=/mingw64/bin/python2 --prefix=/d/opt/rtems/6
--bindir=/d/opt/rtems/6/bin --exec-prefix=/d/opt/rtems/6
--includedir=/d/opt/rtems/6/include --libdir=/d/opt/rtems/6/lib
--mandir=/d/opt/rtems/6/share/man --infodir=/d/opt/rtems/6/share/info

I will try building a mingw gdb not crossed to RTEMS.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/27657] GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom

[cbiesinger at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27657

--- Comment #6 from Christian Biesinger <cbiesinger at google dot com> ---
I can't check the exact build flags right now but I'm pretty sure it was just
disabling binutils/ld/etc. Definitely no host/target flags.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/27657] GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom

[ssbssa at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27657

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

--- Comment #7 from Hannes Domani <ssbssa at sourceware dot org> ---
(In reply to Christian Biesinger from comment #6)
> I can't check the exact build flags right now but I'm pretty sure it was
> just disabling binutils/ld/etc. Definitely no host/target flags.

I think this is a similar issue as in PR26068, in that it only happens with gcc
using a mingw-w64 built with --with-default-win32-winnt=0x601 (win7), because
then gnulib sets LIB_GETRANDOM='-lbcrypt', though I'm not sure how gdb should
now about this.

Also if this is really the problem, I'm surprised this wasn't noticed earlier,
because I thought the msys2 build of gcc also defaults to win7.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/27657] GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom

[ilg at livius dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=27657

Liviu Ionescu <ilg at livius dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ilg at livius dot net

--- Comment #8 from Liviu Ionescu <ilg at livius dot net> ---
I also encountered this bug while compiling GDB 10.2 on Linux, with GCC 11.2 &
mingw-w64 9.0.

In my build I noticed that `-lbcrypt` was not present at all on the linker
invocation line.

Adding `-lbcrypt` to LIBS did not help, since the library must be located later
in the list of libraries.

My initial workaround was to patch configure, but later I found a less
intrusive hack, by adding it as DEBUGINFOD_LIBS, which is placed at the end of
the list:

export DEBUGINFOD_LIBS="-lbcrypt"


I think that configure needs to be fixed to do this automatically, probably if
it detects the presence of `bcrypt.h`.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/27657] GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom

[ovilewade9 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27657

ovile009988 <ovilewade9 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ovilewade9 at gmail dot com

--- Comment #9 from ovile009988 <ovilewade9 at gmail dot com> ---
Thanks for the share here https://myeuchre.com it post look and see free euchre
card game.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug build/27657] GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27657

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-02-27
             Status|UNCONFIRMED                 |NEW

--- Comment #10 from Tom Tromey <tromey at sourceware dot org> ---
Having a check for -lbcrypt seems completely fine to me,
though I wonder if gnulib ought to be doing this, since this
isn't really a direct dependency of gdb.
Anyway it requires someone experiencing this problem to write a patch,
and/or send a bug to gnulib.

-- 
You are receiving this mail because:
You are on the CC list for the bug.