From: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
To: Thomas Monjalon <thomas@monjalon.net>
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, 1 Dec 2020 16:52:36 +0300 [thread overview]
Message-ID: <20201201165236.64b6f97e@sovereign> (raw)
In-Reply-To: <8094293.VoMytXdBYE@thomas>
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.
next prev parent reply other threads:[~2020-12-01 13:52 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 [this message]
2020-12-01 14:05 ` Thomas Monjalon
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=20201201165236.64b6f97e@sovereign \
--to=dmitry.kozliuk@gmail.com \
--cc=dev@dpdk.org \
--cc=dmitrym@microsoft.com \
--cc=navasile@linux.microsoft.com \
--cc=nick.connolly@mayadata.io \
--cc=pallavi.kadam@intel.com \
--cc=talshn@nvidia.com \
--cc=thomas@monjalon.net \
/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).