diff mbox series

eal/windows: fix build warnings in MinGW

Message ID 20210418170803.15684-1-talshn@nvidia.com (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers
Series eal/windows: fix build warnings in MinGW |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/travis-robot success travis build: passed
ci/github-robot success github build: passed
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-testing success Testing PASS
ci/iol-abi-testing success Testing PASS

Commit Message

Tal Shnaiderman April 18, 2021, 5:08 p.m. UTC 
  the strncasecmp marco defined in rte_os_shim.h is already
defined in MinGW-w64, as a result the compiler prints out
the warning below on function redefinition whenever compiling
a file including the header.

..\lib/librte_eal/windows/include/rte_os_shim.h:21:
warning: "strncasecmp" redefined
#define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)

Fixed by defining the marco only to the clang compiler.

Fixes: 45d62067c237 ("eal: make OS shims internal")

Signed-off-by: Tal Shnaiderman <talshn@nvidia.com>
---
 lib/librte_eal/windows/include/rte_os_shim.h | 2 ++
 1 file changed, 2 insertions(+)

Comments

Thomas Monjalon April 18, 2021, 6:13 p.m. UTC | #1 
18/04/2021 19:08, Tal Shnaiderman:
> the strncasecmp marco defined in rte_os_shim.h is already
> defined in MinGW-w64, as a result the compiler prints out
> the warning below on function redefinition whenever compiling
> a file including the header.
> 
> ..\lib/librte_eal/windows/include/rte_os_shim.h:21:
> warning: "strncasecmp" redefined
> #define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)

Why the tests are passing? Are we allowing warnings in build test?

> Fixed by defining the marco only to the clang compiler.

That's a very common typo: s/marco/macro/
Tal Shnaiderman April 18, 2021, 7:04 p.m. UTC | #2 
> Subject: Re: [PATCH] eal/windows: fix build warnings in MinGW
> 
> External email: Use caution opening links or attachments
> 
> 
> 18/04/2021 19:08, Tal Shnaiderman:
> > the strncasecmp marco defined in rte_os_shim.h is already defined in
> > MinGW-w64, as a result the compiler prints out the warning below on
> > function redefinition whenever compiling a file including the header.
> >
> > ..\lib/librte_eal/windows/include/rte_os_shim.h:21:
> > warning: "strncasecmp" redefined
> > #define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)
> 
> Why the tests are passing? Are we allowing warnings in build test?

It's a good question, I see CI is passing without warnings, Dmitry can you reproduce it?

On my side the collision is with the following file:

C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/string.h:119: note: this is the location of the previous definition
 #define strncasecmp _strnicmp

I'm using:
-gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0
-meson 0.53.2

> 
> > Fixed by defining the marco only to the clang compiler.
> 
> That's a very common typo: s/marco/macro/
> 

Thanks, will fix in v2 if this patch is indeed needed.

>
Dmitry Kozlyuk April 18, 2021, 8:23 p.m. UTC | #3 
Hi Tal,

2021-04-18 19:04 (UTC+0000), Tal Shnaiderman:
> > Subject: Re: [PATCH] eal/windows: fix build warnings in MinGW
> > 
> > External email: Use caution opening links or attachments
> > 
> > 
> > 18/04/2021 19:08, Tal Shnaiderman:  
> > > the strncasecmp marco defined in rte_os_shim.h is already defined in
> > > MinGW-w64, as a result the compiler prints out the warning below on
> > > function redefinition whenever compiling a file including the header.
> > >
> > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21:
> > > warning: "strncasecmp" redefined
> > > #define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)  
> > 
> > Why the tests are passing? Are we allowing warnings in build test?  
> 
> It's a good question, I see CI is passing without warnings, Dmitry can you reproduce it?
> 
> On my side the collision is with the following file:
> 
> C:/mingw-w64/x86_64/mingw64/x86_64-w64-mingw32/include/string.h:119: note: this is the location of the previous definition
>  #define strncasecmp _strnicmp
> 
> I'm using:
> -gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0
> -meson 0.53.2

I can't reproduce it using the same versions.
Do you invoke meson with other options than "-Dexamples=..."?
Tal Shnaiderman April 19, 2021, 6:57 a.m. UTC | #4 
> Subject: Re: [PATCH] eal/windows: fix build warnings in MinGW
> 
> External email: Use caution opening links or attachments
> 
> 
> Hi Tal,
> 
> 2021-04-18 19:04 (UTC+0000), Tal Shnaiderman:
> > > Subject: Re: [PATCH] eal/windows: fix build warnings in MinGW
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > 18/04/2021 19:08, Tal Shnaiderman:
> > > > the strncasecmp marco defined in rte_os_shim.h is already defined
> > > > in MinGW-w64, as a result the compiler prints out the warning
> > > > below on function redefinition whenever compiling a file including the
> header.
> > > >
> > > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21:
> > > > warning: "strncasecmp" redefined
> > > > #define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)
> > >
> > > Why the tests are passing? Are we allowing warnings in build test?
> >
> > It's a good question, I see CI is passing without warnings, Dmitry can you
> reproduce it?
> >
> > On my side the collision is with the following file:
> >
> > C:/mingw-w64/x86_64/mingw64/x86_64-w64-
> mingw32/include/string.h:119:
> > note: this is the location of the previous definition  #define
> > strncasecmp _strnicmp
> >
> > I'm using:
> > -gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0 -meson
> > 0.53.2
> 
> I can't reproduce it using the same versions.
> Do you invoke meson with other options than "-Dexamples=..."?

This is the meson line I'm using:

meson "-Dexamples=helloworld" build --wipe --default-library=static --buildtype debug

The problem however is that MinGW's string.h defines the macro in line 119, for some reason my build includes it and the rest doesn't.
Tal Shnaiderman April 19, 2021, 6:06 p.m. UTC | #5 
> Subject: Re: [dpdk-dev] [PATCH] eal/windows: fix build warnings in MinGW
> 
> External email: Use caution opening links or attachments
> 
> 
> > Subject: Re: [PATCH] eal/windows: fix build warnings in MinGW
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Hi Tal,
> >
> > 2021-04-18 19:04 (UTC+0000), Tal Shnaiderman:
> > > > Subject: Re: [PATCH] eal/windows: fix build warnings in MinGW
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > 18/04/2021 19:08, Tal Shnaiderman:
> > > > > the strncasecmp marco defined in rte_os_shim.h is already
> > > > > defined in MinGW-w64, as a result the compiler prints out the
> > > > > warning below on function redefinition whenever compiling a file
> > > > > including the
> > header.
> > > > >
> > > > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21:
> > > > > warning: "strncasecmp" redefined #define strncasecmp(s1, s2,
> > > > > count) _strnicmp(s1, s2, count)
> > > >
> > > > Why the tests are passing? Are we allowing warnings in build test?
> > >
> > > It's a good question, I see CI is passing without warnings, Dmitry
> > > can you
> > reproduce it?
> > >
> > > On my side the collision is with the following file:
> > >
> > > C:/mingw-w64/x86_64/mingw64/x86_64-w64-
> > mingw32/include/string.h:119:
> > > note: this is the location of the previous definition  #define
> > > strncasecmp _strnicmp
> > >
> > > I'm using:
> > > -gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0
> > > -meson
> > > 0.53.2
> >
> > I can't reproduce it using the same versions.
> > Do you invoke meson with other options than "-Dexamples=..."?
> 
> This is the meson line I'm using:
> 
> meson "-Dexamples=helloworld" build --wipe --default-library=static --
> buildtype debug
> 
> The problem however is that MinGW's string.h defines the macro in line 119,
> for some reason my build includes it and the rest doesn't.

Hi Dmitry,

I also noticed warnings in clang on my setup that are related to rte_os_shim.h:

[185/314] Compiling C object drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_common_mp.c.obj.
In file included from ../drivers/common/mlx5/mlx5_common_mp.c:13:
In file included from ..\drivers\common/mlx5/mlx5_common_utils.h:8:
In file included from ..\drivers\common/mlx5/mlx5_common.h:17:
..\lib/librte_eal/windows/include\rte_os_shim.h:22:51: warning: token pasting of ',' and __VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
#define open(path, flags, ...) _open(path, flags, ##__VA_ARGS__)
                                                  ^
However don't see it in CI, I'm using clang version 9.0.1
Thomas Monjalon April 19, 2021, 6:15 p.m. UTC | #6 
19/04/2021 20:06, Tal Shnaiderman:
> > > 2021-04-18 19:04 (UTC+0000), Tal Shnaiderman:
> > > > > 18/04/2021 19:08, Tal Shnaiderman:
> > > > > > the strncasecmp marco defined in rte_os_shim.h is already
> > > > > > defined in MinGW-w64, as a result the compiler prints out the
> > > > > > warning below on function redefinition whenever compiling a file
> > > > > > including the
> > > header.
> > > > > >
> > > > > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21:
> > > > > > warning: "strncasecmp" redefined #define strncasecmp(s1, s2,
> > > > > > count) _strnicmp(s1, s2, count)
> > > > >
> > > > > Why the tests are passing? Are we allowing warnings in build test?
> > > >
> > > > It's a good question, I see CI is passing without warnings, Dmitry
> > > > can you
> > > reproduce it?
> > > >
> > > > On my side the collision is with the following file:
> > > >
> > > > C:/mingw-w64/x86_64/mingw64/x86_64-w64-
> > > mingw32/include/string.h:119:
> > > > note: this is the location of the previous definition  #define
> > > > strncasecmp _strnicmp
> > > >
> > > > I'm using:
> > > > -gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0
> > > > -meson
> > > > 0.53.2
> > >
> > > I can't reproduce it using the same versions.
> > > Do you invoke meson with other options than "-Dexamples=..."?
> > 
> > This is the meson line I'm using:
> > 
> > meson "-Dexamples=helloworld" build --wipe --default-library=static --
> > buildtype debug
> > 
> > The problem however is that MinGW's string.h defines the macro in line 119,
> > for some reason my build includes it and the rest doesn't.
> 
> Hi Dmitry,
> 
> I also noticed warnings in clang on my setup that are related to rte_os_shim.h:
> 
> [185/314] Compiling C object drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_common_mp.c.obj.
> In file included from ../drivers/common/mlx5/mlx5_common_mp.c:13:
> In file included from ..\drivers\common/mlx5/mlx5_common_utils.h:8:
> In file included from ..\drivers\common/mlx5/mlx5_common.h:17:
> ..\lib/librte_eal/windows/include\rte_os_shim.h:22:51: warning: token pasting of ',' and __VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
> #define open(path, flags, ...) _open(path, flags, ##__VA_ARGS__)
>                                                   ^
> However don't see it in CI, I'm using clang version 9.0.1

It seems we should improve our CI.
Please open suggestions in the CI bugzilla.
Dmitry Kozlyuk April 19, 2021, 6:55 p.m. UTC | #7 
2021-04-19 06:57 (UTC+0000), Tal Shnaiderman:
> [...]
> > > > 18/04/2021 19:08, Tal Shnaiderman:  
> > > > > the strncasecmp marco defined in rte_os_shim.h is already defined
> > > > > in MinGW-w64, as a result the compiler prints out the warning
> > > > > below on function redefinition whenever compiling a file including the  
> > header.  
> > > > >
> > > > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21:
> > > > > warning: "strncasecmp" redefined
> > > > > #define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)  
> > > >
> > > > Why the tests are passing? Are we allowing warnings in build test?  
> > >
> > > It's a good question, I see CI is passing without warnings, Dmitry can you  
> > reproduce it?  
> > >
> > > On my side the collision is with the following file:
> > >
> > > C:/mingw-w64/x86_64/mingw64/x86_64-w64-  
> > mingw32/include/string.h:119:  
> > > note: this is the location of the previous definition  #define
> > > strncasecmp _strnicmp
> > >
> > > I'm using:
> > > -gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0 -meson
> > > 0.53.2  
> > 
> > I can't reproduce it using the same versions.
> > Do you invoke meson with other options than "-Dexamples=..."?  
> 
> This is the meson line I'm using:
> 
> meson "-Dexamples=helloworld" build --wipe --default-library=static --buildtype debug
> 
> The problem however is that MinGW's string.h defines the macro in line 119, for some reason my build includes it and the rest doesn't.

--default-library=static it the key, it changes MinGW from using inline
functions to using macros for strncasecmp().
MinGW portion devtools/check-meson-builds.sh should test this variant.

I searched for other defines from rte_os_shim.h in MinGW includes and it
seems strncasecmp() is the only problematic one. Thanks, I'm ready to ack v2
as soon as you send it.
Aaron Conole April 19, 2021, 7:29 p.m. UTC | #8 
Thomas Monjalon <thomas@monjalon.net> writes:

> 19/04/2021 20:06, Tal Shnaiderman:
>> > > 2021-04-18 19:04 (UTC+0000), Tal Shnaiderman:
>> > > > > 18/04/2021 19:08, Tal Shnaiderman:
>> > > > > > the strncasecmp marco defined in rte_os_shim.h is already
>> > > > > > defined in MinGW-w64, as a result the compiler prints out the
>> > > > > > warning below on function redefinition whenever compiling a file
>> > > > > > including the
>> > > header.
>> > > > > >
>> > > > > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21:
>> > > > > > warning: "strncasecmp" redefined #define strncasecmp(s1, s2,
>> > > > > > count) _strnicmp(s1, s2, count)
>> > > > >
>> > > > > Why the tests are passing? Are we allowing warnings in build test?
>> > > >
>> > > > It's a good question, I see CI is passing without warnings, Dmitry
>> > > > can you
>> > > reproduce it?
>> > > >
>> > > > On my side the collision is with the following file:
>> > > >
>> > > > C:/mingw-w64/x86_64/mingw64/x86_64-w64-
>> > > mingw32/include/string.h:119:
>> > > > note: this is the location of the previous definition  #define
>> > > > strncasecmp _strnicmp
>> > > >
>> > > > I'm using:
>> > > > -gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0
>> > > > -meson
>> > > > 0.53.2
>> > >
>> > > I can't reproduce it using the same versions.
>> > > Do you invoke meson with other options than "-Dexamples=..."?
>> > 
>> > This is the meson line I'm using:
>> > 
>> > meson "-Dexamples=helloworld" build --wipe --default-library=static --
>> > buildtype debug
>> > 
>> > The problem however is that MinGW's string.h defines the macro in line 119,
>> > for some reason my build includes it and the rest doesn't.
>> 
>> Hi Dmitry,
>> 
>> I also noticed warnings in clang on my setup that are related to rte_os_shim.h:
>> 
>> [185/314] Compiling C object drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_common_mp.c.obj.
>> In file included from ../drivers/common/mlx5/mlx5_common_mp.c:13:
>> In file included from ..\drivers\common/mlx5/mlx5_common_utils.h:8:
>> In file included from ..\drivers\common/mlx5/mlx5_common.h:17:
>> ..\lib/librte_eal/windows/include\rte_os_shim.h:22:51: warning:
>> token pasting of ',' and __VA_ARGS__ is a GNU extension
>> [-Wgnu-zero-variadic-macro-arguments]
>> #define open(path, flags, ...) _open(path, flags, ##__VA_ARGS__)
>>                                                   ^
>> However don't see it in CI, I'm using clang version 9.0.1
>
> It seems we should improve our CI.
> Please open suggestions in the CI bugzilla.

Please do.

Will this only be caught by mingw64 on windows?  Will we get the same
issues with a linux mingw install?  I'm guessing yes, but don't know
mingw very well.  We may be able to install the mingw package under our
github actions pipeline.
Dmitry Kozlyuk April 19, 2021, 7:45 p.m. UTC | #9 
Hi Tal,

2021-04-19 18:06 (UTC+0000), Tal Shnaiderman:
> I also noticed warnings in clang on my setup that are related to rte_os_shim.h:
> 
> [185/314] Compiling C object drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_common_mp.c.obj.
> In file included from ../drivers/common/mlx5/mlx5_common_mp.c:13:
> In file included from ..\drivers\common/mlx5/mlx5_common_utils.h:8:
> In file included from ..\drivers\common/mlx5/mlx5_common.h:17:
> ..\lib/librte_eal/windows/include\rte_os_shim.h:22:51: warning: token pasting of ',' and __VA_ARGS__ is a GNU extension [-Wgnu-zero-variadic-macro-arguments]
> #define open(path, flags, ...) _open(path, flags, ##__VA_ARGS__)
>                                                   ^
> However don't see it in CI, I'm using clang version 9.0.1

This warning only appears with --buildtype=debug, that's why I missed it.
I don't see a good way to fix it except #define open _open,
RTE_FMT_xxx approach is not applicable here.
Dmitry Kozlyuk April 19, 2021, 8:09 p.m. UTC | #10 
2021-04-19 15:29 (UTC-0400), Aaron Conole:
> Thomas Monjalon <thomas@monjalon.net> writes:
> 
> > 19/04/2021 20:06, Tal Shnaiderman:  
> >> > > 2021-04-18 19:04 (UTC+0000), Tal Shnaiderman:  
> >> > > > > 18/04/2021 19:08, Tal Shnaiderman:  
> >> > > > > > the strncasecmp marco defined in rte_os_shim.h is already
> >> > > > > > defined in MinGW-w64, as a result the compiler prints out the
> >> > > > > > warning below on function redefinition whenever compiling a file
> >> > > > > > including the  
> >> > > header.  
> >> > > > > >
> >> > > > > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21:
> >> > > > > > warning: "strncasecmp" redefined #define strncasecmp(s1, s2,
> >> > > > > > count) _strnicmp(s1, s2, count)  
> >> > > > >
> >> > > > > Why the tests are passing? Are we allowing warnings in build test?  
> >> > > >
> >> > > > It's a good question, I see CI is passing without warnings, Dmitry
> >> > > > can you  
> >> > > reproduce it?  
> >> > > >
> >> > > > On my side the collision is with the following file:
> >> > > >
> >> > > > C:/mingw-w64/x86_64/mingw64/x86_64-w64-  
> >> > > mingw32/include/string.h:119:  
> >> > > > note: this is the location of the previous definition  #define
> >> > > > strncasecmp _strnicmp
> >> > > >
> >> > > > I'm using:
> >> > > > -gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0
> >> > > > -meson
> >> > > > 0.53.2  
> >> > >
> >> > > I can't reproduce it using the same versions.
> >> > > Do you invoke meson with other options than "-Dexamples=..."?  
> >> > 
> >> > This is the meson line I'm using:
> >> > 
> >> > meson "-Dexamples=helloworld" build --wipe --default-library=static --
> >> > buildtype debug
> >> > 
> >> > The problem however is that MinGW's string.h defines the macro in line 119,
> >> > for some reason my build includes it and the rest doesn't.  
> >> 
> >> Hi Dmitry,
> >> 
> >> I also noticed warnings in clang on my setup that are related to rte_os_shim.h:
> >> 
> >> [185/314] Compiling C object drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_common_mp.c.obj.
> >> In file included from ../drivers/common/mlx5/mlx5_common_mp.c:13:
> >> In file included from ..\drivers\common/mlx5/mlx5_common_utils.h:8:
> >> In file included from ..\drivers\common/mlx5/mlx5_common.h:17:
> >> ..\lib/librte_eal/windows/include\rte_os_shim.h:22:51: warning:
> >> token pasting of ',' and __VA_ARGS__ is a GNU extension
> >> [-Wgnu-zero-variadic-macro-arguments]
> >> #define open(path, flags, ...) _open(path, flags, ##__VA_ARGS__)
> >>                                                   ^
> >> However don't see it in CI, I'm using clang version 9.0.1  
> >
> > It seems we should improve our CI.
> > Please open suggestions in the CI bugzilla.  
> 
> Please do.
> 
> Will this only be caught by mingw64 on windows?  Will we get the same
> issues with a linux mingw install?  I'm guessing yes, but don't know
> mingw very well.  We may be able to install the mingw package under our
> github actions pipeline.

Yes, Linux MinGW-w64 produces the same warning (about strncasecmp).
__VA_ARGS__ warning won't show up with GNU compiler, obviously.
It may with ICC, but I don't have it to check.

I figured out it's not --default-library=static, but --buildtype=debug that
caues the arning to appear, my mistake in previous message.
Lincoln Lavoie April 19, 2021, 8:33 p.m. UTC | #11 
Is that related to a recent patch (I think it was David's, but don't quote
me on that) that enabled a debug build mode when it sees git repo info
within the build root?

Cheers,
Lincoln

On Mon, Apr 19, 2021 at 4:09 PM Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
wrote:

> 2021-04-19 15:29 (UTC-0400), Aaron Conole:
> > Thomas Monjalon <thomas@monjalon.net> writes:
> >
> > > 19/04/2021 20:06, Tal Shnaiderman:
> > >> > > 2021-04-18 19:04 (UTC+0000), Tal Shnaiderman:
> > >> > > > > 18/04/2021 19:08, Tal Shnaiderman:
> > >> > > > > > the strncasecmp marco defined in rte_os_shim.h is already
> > >> > > > > > defined in MinGW-w64, as a result the compiler prints out
> the
> > >> > > > > > warning below on function redefinition whenever compiling a
> file
> > >> > > > > > including the
> > >> > > header.
> > >> > > > > >
> > >> > > > > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21:
> > >> > > > > > warning: "strncasecmp" redefined #define strncasecmp(s1, s2,
> > >> > > > > > count) _strnicmp(s1, s2, count)
> > >> > > > >
> > >> > > > > Why the tests are passing? Are we allowing warnings in build
> test?
> > >> > > >
> > >> > > > It's a good question, I see CI is passing without warnings,
> Dmitry
> > >> > > > can you
> > >> > > reproduce it?
> > >> > > >
> > >> > > > On my side the collision is with the following file:
> > >> > > >
> > >> > > > C:/mingw-w64/x86_64/mingw64/x86_64-w64-
> > >> > > mingw32/include/string.h:119:
> > >> > > > note: this is the location of the previous definition  #define
> > >> > > > strncasecmp _strnicmp
> > >> > > >
> > >> > > > I'm using:
> > >> > > > -gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project) 8.1.0
> > >> > > > -meson
> > >> > > > 0.53.2
> > >> > >
> > >> > > I can't reproduce it using the same versions.
> > >> > > Do you invoke meson with other options than "-Dexamples=..."?
> > >> >
> > >> > This is the meson line I'm using:
> > >> >
> > >> > meson "-Dexamples=helloworld" build --wipe --default-library=static
> --
> > >> > buildtype debug
> > >> >
> > >> > The problem however is that MinGW's string.h defines the macro in
> line 119,
> > >> > for some reason my build includes it and the rest doesn't.
> > >>
> > >> Hi Dmitry,
> > >>
> > >> I also noticed warnings in clang on my setup that are related to
> rte_os_shim.h:
> > >>
> > >> [185/314] Compiling C object drivers/a715181@@tmp_rte_common_mlx5@sta
> /common_mlx5_mlx5_common_mp.c.obj.
> > >> In file included from ../drivers/common/mlx5/mlx5_common_mp.c:13:
> > >> In file included from ..\drivers\common/mlx5/mlx5_common_utils.h:8:
> > >> In file included from ..\drivers\common/mlx5/mlx5_common.h:17:
> > >> ..\lib/librte_eal/windows/include\rte_os_shim.h:22:51: warning:
> > >> token pasting of ',' and __VA_ARGS__ is a GNU extension
> > >> [-Wgnu-zero-variadic-macro-arguments]
> > >> #define open(path, flags, ...) _open(path, flags, ##__VA_ARGS__)
> > >>                                                   ^
> > >> However don't see it in CI, I'm using clang version 9.0.1
> > >
> > > It seems we should improve our CI.
> > > Please open suggestions in the CI bugzilla.
> >
> > Please do.
> >
> > Will this only be caught by mingw64 on windows?  Will we get the same
> > issues with a linux mingw install?  I'm guessing yes, but don't know
> > mingw very well.  We may be able to install the mingw package under our
> > github actions pipeline.
>
> Yes, Linux MinGW-w64 produces the same warning (about strncasecmp).
> __VA_ARGS__ warning won't show up with GNU compiler, obviously.
> It may with ICC, but I don't have it to check.
>
> I figured out it's not --default-library=static, but --buildtype=debug that
> caues the arning to appear, my mistake in previous message.
>
Tal Shnaiderman April 20, 2021, 11:01 a.m. UTC | #12 
> Subject: Re: [dpdk-ci] [PATCH] eal/windows: fix build warnings in MinGW
> 
> External email: Use caution opening links or attachments
> 
> 
> 2021-04-19 15:29 (UTC-0400), Aaron Conole:
> > Thomas Monjalon <thomas@monjalon.net> writes:
> >
> > > 19/04/2021 20:06, Tal Shnaiderman:
> > >> > > 2021-04-18 19:04 (UTC+0000), Tal Shnaiderman:
> > >> > > > > 18/04/2021 19:08, Tal Shnaiderman:
> > >> > > > > > the strncasecmp marco defined in rte_os_shim.h is already
> > >> > > > > > defined in MinGW-w64, as a result the compiler prints out
> > >> > > > > > the warning below on function redefinition whenever
> > >> > > > > > compiling a file including the
> > >> > > header.
> > >> > > > > >
> > >> > > > > > ..\lib/librte_eal/windows/include/rte_os_shim.h:21:
> > >> > > > > > warning: "strncasecmp" redefined #define strncasecmp(s1,
> > >> > > > > > s2,
> > >> > > > > > count) _strnicmp(s1, s2, count)
> > >> > > > >
> > >> > > > > Why the tests are passing? Are we allowing warnings in build
> test?
> > >> > > >
> > >> > > > It's a good question, I see CI is passing without warnings,
> > >> > > > Dmitry can you
> > >> > > reproduce it?
> > >> > > >
> > >> > > > On my side the collision is with the following file:
> > >> > > >
> > >> > > > C:/mingw-w64/x86_64/mingw64/x86_64-w64-
> > >> > > mingw32/include/string.h:119:
> > >> > > > note: this is the location of the previous definition
> > >> > > > #define strncasecmp _strnicmp
> > >> > > >
> > >> > > > I'm using:
> > >> > > > -gcc (x86_64-win32-seh-rev0, Built by MinGW-W64 project)
> > >> > > > 8.1.0 -meson
> > >> > > > 0.53.2
> > >> > >
> > >> > > I can't reproduce it using the same versions.
> > >> > > Do you invoke meson with other options than "-Dexamples=..."?
> > >> >
> > >> > This is the meson line I'm using:
> > >> >
> > >> > meson "-Dexamples=helloworld" build --wipe
> > >> > --default-library=static -- buildtype debug
> > >> >
> > >> > The problem however is that MinGW's string.h defines the macro in
> > >> > line 119, for some reason my build includes it and the rest doesn't.
> > >>
> > >> Hi Dmitry,
> > >>
> > >> I also noticed warnings in clang on my setup that are related to
> rte_os_shim.h:
> > >>
> > >> [185/314] Compiling C object
> drivers/a715181@@tmp_rte_common_mlx5@sta/common_mlx5_mlx5_co
> mmon_mp.c.obj.
> > >> In file included from ../drivers/common/mlx5/mlx5_common_mp.c:13:
> > >> In file included from ..\drivers\common/mlx5/mlx5_common_utils.h:8:
> > >> In file included from ..\drivers\common/mlx5/mlx5_common.h:17:
> > >> ..\lib/librte_eal/windows/include\rte_os_shim.h:22:51: warning:
> > >> token pasting of ',' and __VA_ARGS__ is a GNU extension
> > >> [-Wgnu-zero-variadic-macro-arguments]
> > >> #define open(path, flags, ...) _open(path, flags, ##__VA_ARGS__)
> > >>                                                   ^ However don't
> > >> see it in CI, I'm using clang version 9.0.1
> > >
> > > It seems we should improve our CI.
> > > Please open suggestions in the CI bugzilla.
> >
> > Please do.
> >
> > Will this only be caught by mingw64 on windows?  Will we get the same
> > issues with a linux mingw install?  I'm guessing yes, but don't know
> > mingw very well.  We may be able to install the mingw package under
> > our github actions pipeline.
> 
> Yes, Linux MinGW-w64 produces the same warning (about strncasecmp).
> __VA_ARGS__ warning won't show up with GNU compiler, obviously.
> It may with ICC, but I don't have it to check.
> 
> I figured out it's not --default-library=static, but --buildtype=debug that
> caues the arning to appear, my mistake in previous message.

Right, using --buildtype=release doesn't reproduce the error.

BTW, how does release build passes if I excluded the definition from RTE_TOOLCHAIN_GCC?
diff mbox series

Patch

diff --git a/lib/librte_eal/windows/include/rte_os_shim.h b/lib/librte_eal/windows/include/rte_os_shim.h
index f40fb62d1d..db0ea6f1b3 100644
--- a/lib/librte_eal/windows/include/rte_os_shim.h
+++ b/lib/librte_eal/windows/include/rte_os_shim.h
@@ -17,7 +17,9 @@ 
 
 #define strdup(str) _strdup(str)
 #define strtok_r(str, delim, saveptr) strtok_s(str, delim, saveptr)
+#ifndef RTE_TOOLCHAIN_GCC
 #define strncasecmp(s1, s2, count) _strnicmp(s1, s2, count)
+#endif
 
 #define open(path, flags, ...) _open(path, flags, ##__VA_ARGS__)
 #define read(fd, buf, n) _read(fd, buf, n)