From: Nick Connolly <nick.connolly@mayadata.io>
To: David Marchand <david.marchand@redhat.com>,
Pallavi Kadam <pallavi.kadam@intel.com>,
Bruce Richardson <bruce.richardson@intel.com>
Cc: dev <dev@dpdk.org>, Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>,
Narcisa Ana Maria Vasile <navasile@linux.microsoft.com>,
"Dmitry Malloy (MESHCHANINOV)" <dmitrym@microsoft.com>
Subject: Re: [dpdk-dev] Build error with mingw in debug mode
Date: Fri, 27 Nov 2020 12:09:16 +0000 [thread overview]
Message-ID: <2fba3d4e-767e-c0e2-6a86-98181fd1ce6e@mayadata.io> (raw)
In-Reply-To: <68b89ead-32f1-bd69-d690-a0ed564fbd20@mayadata.io>
I've created a patch for this and also for a couple of build warnings
that showed up doing
a similar test with clang.
On 27/11/2020 10:07, Nick Connolly wrote:
> Errata: the definition is in rte_os.h rather than rte_windows.h
>
> On 27/11/2020 10:05, Nick Connolly wrote:
>> The root cause here is that rte_windows.h shouldn't be injecting
>> 'missing' POSIX functionality
>> into the environment. The header is included indirectly in
>> application code via rte_os.h, but
>> deciding how to implement the 'missing' functionality should be the
>> applications responsibility.
>>
>> There are a number of definitions that fall in this category, so
>> there will need to be some work
>> done to resolve the issues.
>>
>> In the meantime, I'll prepare a patch that works around the specific
>> issue you've encountered.
>>
>> Regards,
>> Nick
>>
>> On 27/11/2020 09:53, David Marchand wrote:
>>> This is introduced by e8428a9d89f1 ("eal/windows: add some basic
>>> functions and macros").
>>> So sending to you guys:
>>>
>>> Caught while compiling all my envs with --buildtype=debug rather than
>>> debugoptimized:
>>>
>>> ninja: Entering directory `/home/dmarchan/builds/build-x86-mingw'
>>> ...
>>> Build targets in project: 70
>>> Option buildtype is: debug [default: release]
>>> Found ninja-1.9.0 at /usr/bin/ninja
>>> [1/149] Compiling C object
>>> 'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_hexdump.c.obj'.
>>> FAILED:
>>> lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_hexdump.c.obj
>>> x86_64-w64-mingw32-gcc -Ilib/76b5a35@@rte_eal@sta -Ilib
>>> -I../../dpdk/lib -I. -I../../dpdk/ -Iconfig -I../../dpdk/config
>>> -Ilib/librte_eal/include -I../../dpdk/lib/librte_eal/include
>>> -Ilib/librte_eal/windows/include
>>> -I../../dpdk/lib/librte_eal/windows/include
>>> -Ilib/librte_eal/x86/include -I../../dpdk/lib/librte_eal/x86/include
>>> -Ilib/librte_eal/common -I../../dpdk/lib/librte_eal/common
>>> -Ilib/librte_eal -I../../dpdk/lib/librte_eal -Ilib/librte_kvargs
>>> -I../../dpdk/lib/librte_kvargs -fdiagnostics-color=always -pipe -Wall
>>> -Winvalid-pch -Werror -g -include rte_config.h -Wextra -Wcast-qual
>>> -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security
>>> -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
>>> -Wold-style-definition -Wpointer-arith -Wsign-compare
>>> -Wstrict-prototypes -Wundef -Wwrite-strings
>>> -Wno-address-of-packed-member -Wno-packed-not-aligned
>>> -Wno-missing-field-initializers -D_GNU_SOURCE -D_WIN32_WINNT=0x0A00
>>> -D__USE_MINGW_ANSI_STDIO -march=native -DALLOW_EXPERIMENTAL_API
>>> -DALLOW_INTERNAL_API -Wno-format-truncation '-DABI_VERSION="21.0"' -MD
>>> -MQ
>>> 'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_hexdump.c.obj'
>>> -MF
>>> 'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_hexdump.c.obj.d'
>>> -o
>>> 'lib/76b5a35@@rte_eal@sta/librte_eal_common_eal_common_hexdump.c.obj'
>>> -c ../../dpdk/lib/librte_eal/common/eal_common_hexdump.c
>>> In file included from
>>> ../../dpdk/lib/librte_eal/include/rte_common.h:28,
>>> from
>>> ../../dpdk/lib/librte_eal/include/rte_string_fns.h:21,
>>> from
>>> ../../dpdk/lib/librte_eal/common/eal_common_hexdump.c:9:
>>> ../../dpdk/lib/librte_eal/windows/include/rte_os.h:40: error:
>>> "strncasecmp" redefined [-Werror]
>>> 40 | #define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)
>>> |
>>> In file included from
>>> ../../dpdk/lib/librte_eal/include/rte_string_fns.h:19,
>>> from
>>> ../../dpdk/lib/librte_eal/common/eal_common_hexdump.c:9:
>>> /usr/x86_64-w64-mingw32/sys-root/mingw/include/string.h:119: note:
>>> this is the location of the previous definition
>>> 119 | #define strncasecmp _strnicmp
>>> |
>>> cc1: all warnings being treated as errors
>>>
>>>
>>
>
prev parent reply other threads:[~2020-11-27 12:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-27 9:53 David Marchand
2020-11-27 10:05 ` Nick Connolly
2020-11-27 10:07 ` Nick Connolly
2020-11-27 12:09 ` Nick Connolly [this message]
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=2fba3d4e-767e-c0e2-6a86-98181fd1ce6e@mayadata.io \
--to=nick.connolly@mayadata.io \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=dmitrym@microsoft.com \
--cc=navasile@linux.microsoft.com \
--cc=pallavi.kadam@intel.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).