Unable to build GDB on Windows

Unable to build GDB on Windows

[Simon Cook]

Hello,

I've been trying to build top of tree GDB on Windows (natively under
the MSYS2 environment), and haven't been able to link successfully due
to undefined symbols after linking against gnulib:

    CXXLD  gdb.exe
  ../gnulib/import/libgnu.a(getrandom.o): In function `getrandom':
  C:\msys64s\home\simon\work\b\gnulib\import/../../../binutils-gdb/gnulib/import/getrandom.c:129:
undefined reference to `BCryptGenRandom'
  collect2.exe: error: ld returned 1 exit status

Reading through the source file and gnulib/import/m4/getrandom.m4, it
suggests that in my case if bcrypt can be guaranteed to be present
then I should add -lbcrypt to my linker flags to resolve these
references, and indeed if I execute the failing gdb link command and
add -lbcrypt at the end then my link succeeds.

Is this an issue that anyone has seen before? It's not clear on my
side whether there's an issue with my environment causing that
dependency to be needed, and something missing from the GDB makefiles.

Many thanks,
Simon

Re: Unable to build GDB on Windows

[Eli Zaretskii]

> From: Simon Cook <simon.cook@embecosm.com>
> Date: Mon, 28 Sep 2020 14:47:25 +0100
> 
> I've been trying to build top of tree GDB on Windows (natively under
> the MSYS2 environment), and haven't been able to link successfully due
> to undefined symbols after linking against gnulib:
> 
>     CXXLD  gdb.exe
>   ../gnulib/import/libgnu.a(getrandom.o): In function `getrandom':
>   C:\msys64s\home\simon\work\b\gnulib\import/../../../binutils-gdb/gnulib/import/getrandom.c:129:
> undefined reference to `BCryptGenRandom'
>   collect2.exe: error: ld returned 1 exit status
> 
> Reading through the source file and gnulib/import/m4/getrandom.m4, it
> suggests that in my case if bcrypt can be guaranteed to be present
> then I should add -lbcrypt to my linker flags to resolve these
> references, and indeed if I execute the failing gdb link command and
> add -lbcrypt at the end then my link succeeds.

What version of MS-Windows is that?

What is the value of gl_cv_lib_assume_bcrypt in gnulib/config.cache?
And what do you see in gnulib/config.log about the test

  checking whether the bcrypt library is guaranteed to be present

> Is this an issue that anyone has seen before? It's not clear on my
> side whether there's an issue with my environment causing that
> dependency to be needed, and something missing from the GDB makefiles.

Hmm, looks like we are missing LIB_GETRANDOM in gdb/Makefile?

Re: Unable to build GDB on Windows

[Eli Zaretskii]

> Date: Mon, 28 Sep 2020 17:25:25 +0300
> From: Eli Zaretskii via Gdb <gdb@sourceware.org>
> Cc: gdb@sourceware.org
> 
> > From: Simon Cook <simon.cook@embecosm.com>
> > Date: Mon, 28 Sep 2020 14:47:25 +0100
> > 
> > I've been trying to build top of tree GDB on Windows (natively under
> > the MSYS2 environment), and haven't been able to link successfully due
> > to undefined symbols after linking against gnulib:
> > 
> >     CXXLD  gdb.exe
> >   ../gnulib/import/libgnu.a(getrandom.o): In function `getrandom':
> >   C:\msys64s\home\simon\work\b\gnulib\import/../../../binutils-gdb/gnulib/import/getrandom.c:129:
> > undefined reference to `BCryptGenRandom'
> >   collect2.exe: error: ld returned 1 exit status
> > 
> > Reading through the source file and gnulib/import/m4/getrandom.m4, it
> > suggests that in my case if bcrypt can be guaranteed to be present
> > then I should add -lbcrypt to my linker flags to resolve these
> > references, and indeed if I execute the failing gdb link command and
> > add -lbcrypt at the end then my link succeeds.

Btw, looking at Gnulib's getrandom.c, my conclusion is that a GDB
built on Windows 7 and later will be unable to run on older versions
of Windows, because it will have a static dependency on bcrypt.dll and
the BCryptGenRandom function from that DLL.  IOW, such a GDB will
refuse to run on older Windows systems.

OTOH, if you build on Windows before 7, the produced binary will be
able to run on newer versions of Windows by dynamically loading
bcrypt.dll (when available) at run time, and using a fallback
otherwise.

Perhaps no one cares about Windows 7 and older anymore, but I just
wanted to say this FTR, in case someone bumps into such a problem.

Re: Unable to build GDB on Windows

[Simon Cook]

On Mon, Sep 28, 2020 at 3:25 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> What version of MS-Windows is that?

I'm building on 64-bit Windows 10 (version 2004 if that's relevant)

> What is the value of gl_cv_lib_assume_bcrypt in gnulib/config.cache?

gl_cv_lib_assume_bcrypt=${gl_cv_lib_assume_bcrypt=yes}

> And what do you see in gnulib/config.log about the test
>
>   checking whether the bcrypt library is guaranteed to be present
>

configure:20630: checking whether the bcrypt library is guaranteed to be present
configure:20650: gcc -c -g -O2 -D__USE_MINGW_ACCESS  conftest.c >&5
configure:20650: $? = 0
configure:20658: result: yes

Re: Unable to build GDB on Windows

[Eli Zaretskii]

> From: Simon Cook <simon.cook@embecosm.com>
> Date: Mon, 28 Sep 2020 16:02:53 +0100
> Cc: gdb@sourceware.org
> 
> On Mon, Sep 28, 2020 at 3:25 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > What version of MS-Windows is that?
> 
> I'm building on 64-bit Windows 10 (version 2004 if that's relevant)
> 
> > What is the value of gl_cv_lib_assume_bcrypt in gnulib/config.cache?
> 
> gl_cv_lib_assume_bcrypt=${gl_cv_lib_assume_bcrypt=yes}
> 
> > And what do you see in gnulib/config.log about the test
> >
> >   checking whether the bcrypt library is guaranteed to be present
> >
> 
> configure:20630: checking whether the bcrypt library is guaranteed to be present
> configure:20650: gcc -c -g -O2 -D__USE_MINGW_ACCESS  conftest.c >&5
> configure:20650: $? = 0
> configure:20658: result: yes

Then I guess the problem is indeed that gdb/Makefile doesn't use
LIB_GETRANDOM, which getrandom.m4 sets as part of the above test.

Re: Unable to build GDB on Windows

[Joel Brobecker]

> Btw, looking at Gnulib's getrandom.c, my conclusion is that a GDB
> built on Windows 7 and later will be unable to run on older versions
> of Windows, because it will have a static dependency on bcrypt.dll and
> the BCryptGenRandom function from that DLL.  IOW, such a GDB will
> refuse to run on older Windows systems.

I think that's fine. IMO, the general spirit should be that people
interested in building a GDB that works on multiple versions of
an OS should build it on the oldest version they want to support.
I don't think we want to commit to anything stronger than that.

-- 
Joel

Re: Unable to build GDB on Windows

[Christian Biesinger]

On Mon, Sep 28, 2020 at 4:44 PM Eli Zaretskii via Gdb
<gdb@sourceware.org> wrote:
> Btw, looking at Gnulib's getrandom.c, my conclusion is that a GDB
> built on Windows 7 and later will be unable to run on older versions
> of Windows, because it will have a static dependency on bcrypt.dll and
> the BCryptGenRandom function from that DLL.  IOW, such a GDB will
> refuse to run on older Windows systems.
>
> OTOH, if you build on Windows before 7, the produced binary will be
> able to run on newer versions of Windows by dynamically loading
> bcrypt.dll (when available) at run time, and using a fallback
> otherwise.

Hmm that sounds odd, usually the way the Windows SDK works is that
this only depends on what you #define, not what you build on
(especially _WIN32_WINNT)

Christian

Re: Unable to build GDB on Windows

[Eli Zaretskii]

> Date: Mon, 28 Sep 2020 08:15:23 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> > Btw, looking at Gnulib's getrandom.c, my conclusion is that a GDB
> > built on Windows 7 and later will be unable to run on older versions
> > of Windows, because it will have a static dependency on bcrypt.dll and
> > the BCryptGenRandom function from that DLL.  IOW, such a GDB will
> > refuse to run on older Windows systems.
> 
> I think that's fine. IMO, the general spirit should be that people
> interested in building a GDB that works on multiple versions of
> an OS should build it on the oldest version they want to support.
> I don't think we want to commit to anything stronger than that.

Maybe just say that in some README?

Re: Unable to build GDB on Windows

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Mon, 28 Sep 2020 17:17:49 +0200
> Cc: simon.cook@embecosm.com, Reuben Thomas via Gdb <gdb@sourceware.org>
> 
> > OTOH, if you build on Windows before 7, the produced binary will be
> > able to run on newer versions of Windows by dynamically loading
> > bcrypt.dll (when available) at run time, and using a fallback
> > otherwise.
> 
> Hmm that sounds odd, usually the way the Windows SDK works is that
> this only depends on what you #define, not what you build on
> (especially _WIN32_WINNT)

Well, that's true, but how many will use "CPPFLAGS=-D_WIN32_WINNT=..."
when configuring GDB?  The default is buried somewhere in the MinGW
headers, and guess what it is?

Re: Unable to build GDB on Windows

[Eli Zaretskii]

> Date: Mon, 28 Sep 2020 18:23:39 +0300
> From: Eli Zaretskii via Gdb <gdb@sourceware.org>
> Cc: gdb@sourceware.org
> 
> > From: Christian Biesinger <cbiesinger@google.com>
> > Date: Mon, 28 Sep 2020 17:17:49 +0200
> > Cc: simon.cook@embecosm.com, Reuben Thomas via Gdb <gdb@sourceware.org>
> > 
> > Hmm that sounds odd, usually the way the Windows SDK works is that
> > this only depends on what you #define, not what you build on
> > (especially _WIN32_WINNT)
> 
> Well, that's true, but how many will use "CPPFLAGS=-D_WIN32_WINNT=..."
> when configuring GDB?  The default is buried somewhere in the MinGW
> headers, and guess what it is?

And actually, in this case the above is not relevant.  Because
getrandom.c bases its logic on the configure-time test that results in
HAVE_LIB_BCRYPT defined to either 1 or zero.  It doesn't look at
_WIN32_WINNT at all.  So yes, the result depends on whether you build
GDB on a system with or without bcrypt.dll.