Bug 27657 - GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom
Summary: GDB fails to link on MSYS2 and mingw64 looking for BCryptGenRandom
Status: UNCONFIRMED
Alias: None
Product: gdb
Classification: Unclassified
Component: build (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-28 06:06 UTC by Chris Johns
Modified: 2021-09-03 15:04 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Johns 2021-03-28 06:06:49 UTC
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.
Comment 1 Chris Johns 2021-03-29 04:29:26 UTC
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?
Comment 2 Tom Tromey 2021-03-29 15:53:17 UTC
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.
Comment 3 Christian Biesinger 2021-03-29 20:10:50 UTC
Hmm, something must be different on my system, I don't see this link error on msys2...
Comment 4 Chris Johns 2021-03-29 20:41:37 UTC
(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.
Comment 5 Chris Johns 2021-03-29 20:46:02 UTC
(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.
Comment 6 Christian Biesinger 2021-03-29 23:29:43 UTC
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.
Comment 7 Hannes Domani 2021-03-30 15:58:20 UTC
(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.
Comment 8 Liviu Ionescu 2021-08-26 10:38:44 UTC
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`.
Comment 9 ovile009988 2021-09-03 15:04:28 UTC Comment hidden (spam)