From: Thomas Monjalon <thomas@monjalon.net>
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Cc: nick.connolly@mayadata.io, navasile@linux.microsoft.com,
dmitrym@microsoft.com, pallavi.kadam@intel.com,
talshn@nvidia.com, dev@dpdk.org
Subject: Re: [dpdk-dev] build failure with MinGW GCC 10.2
Date: Tue, 01 Dec 2020 15:05:33 +0100 [thread overview]
Message-ID: <7845567.VZ0XykoOHZ@thomas> (raw)
In-Reply-To: <20201201165236.64b6f97e@sovereign>
01/12/2020 14:52, Dmitry Kozlyuk:
> On Tue, 01 Dec 2020 14:18:53 +0100, Thomas Monjalon wrote:
> > Hi,
> >
> > I'm hitting an issue with x86_64-w64-mingw32-gcc (GCC) 10.2.0:
> > lib/librte_eal/windows/eal_memory.c:30:14: error:
> > redeclaration of ‘enum MEM_EXTENDED_PARAMETER_TYPE’
> > and others:
> > redeclaration of enumerator ‘MemExtendedParameterInvalidType’
> > redeclaration of enumerator ‘MemExtendedParameterAddressRequirements’
> > redeclaration of enumerator ‘MemExtendedParameterNumaNode’
> > redeclaration of enumerator ‘MemExtendedParameterPartitionHandle’
> > redeclaration of enumerator ‘MemExtendedParameterUserPhysicalHandle’
> > redeclaration of enumerator ‘MemExtendedParameterAttributeFlags’
> > redeclaration of enumerator ‘MemExtendedParameterMax’
> > redefinition of ‘struct MEM_EXTENDED_PARAMETER’
> > "MEM_EXTENDED_PARAMETER_TYPE_BITS" redefined
> >
> > I see in the code it should be avoided:
> >
> > /* MinGW-w64 headers lack VirtualAlloc2() in some distributions.
> > * Provide a copy of definitions and code to load it dynamically.
> > * Note: definitions are copied verbatim from Microsoft documentation
> > * and don't follow DPDK code style.
> > *
> > * MEM_RESERVE_PLACEHOLDER being defined means VirtualAlloc2() is present too.
> > */
> > #ifndef MEM_PRESERVE_PLACEHOLDER
> >
> > Does it mean using this flag is not true anymore in recent MinGW?
>
> I think the #ifndef test is incorrect, maybe MEM_PRESERVE_PLACEHOLDER is not
> a macro in MinGW headers as it is in Windows SDK.
>
> What's your environment?
>
> I can't reproduce this with the latest MinGW-w64 8.0.0 for Windows from
> https://sourceforge.net/projects/mingw-w64/files/, x86_64-win32-seh flavour
> (GCC 8.1.0), and neither with MinGW-w64 6.0.0 (9.3.0) on NixOS.
I am using ArchLinux:
mingw-w64-gcc 10.2.0-2
mingw-w64-headers 8.0.0-1
mingw-w64-crt 8.0.0-1
next prev parent reply other threads:[~2020-12-01 14:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-01 13:18 Thomas Monjalon
2020-12-01 13:52 ` Dmitry Kozlyuk
2020-12-01 14:05 ` Thomas Monjalon [this message]
2020-12-01 14:37 ` Dmitry Kozlyuk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7845567.VZ0XykoOHZ@thomas \
--to=thomas@monjalon.net \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=dmitrym@microsoft.com \
--cc=navasile@linux.microsoft.com \
--cc=nick.connolly@mayadata.io \
--cc=pallavi.kadam@intel.com \
--cc=talshn@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).