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 ..
The repo we clone is a mirror of yours on github ...
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 ...
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 126.96.36.19928.07922837-1
This looks like an archive wrapper for the standard Windows DLL.
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?
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.
Hmm, something must be different on my system, I don't see this link error on msys2...
(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.
(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.
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.
(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.
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:
I think that configure needs to be fixed to do this automatically, probably if it detects the presence of `bcrypt.h`.
Thanks for the share here https://myeuchre.com it post look and see free euchre card game.