eal/windows: fix link error with MinGW

Message ID 20201120211255.24803-1-nick.connolly@mayadata.io (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers
Series eal/windows: fix link error with MinGW |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS
ci/iol-testing warning Testing issues
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/Intel-compilation success Compilation OK
ci/travis-robot success Travis build: passed

Commit Message

Nick Connolly Nov. 20, 2020, 9:12 p.m. UTC
  Linking with the 'pci' driver when building with MinGW on
Windows fails with undefined symbol 'GUID_DEVCLASS_NET'.
This occurs because devguid.h is included in rte_windows.h
before INITGUID is defined.

Resolved by moving the include of devguid.h after the definition
of INITGUID.

Fixes: b762221ac24f ("bus/pci: support Windows with bifurcated drivers")
Cc: talshn@mellanox.com
Signed-off-by: Nick Connolly <nick.connolly@mayadata.io>
---
 lib/librte_eal/windows/include/rte_windows.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Comments

Tal Shnaiderman Nov. 20, 2020, 10:41 p.m. UTC | #1
> Subject: [PATCH] eal/windows: fix link error with MinGW
> 
> Linking with the 'pci' driver when building with MinGW on Windows fails with
> undefined symbol 'GUID_DEVCLASS_NET'.
> This occurs because devguid.h is included in rte_windows.h before INITGUID
> is defined.
> 

Hi Nick, 

I can't seem to reproduce the link error you've mentioned (I'm building hello_world on master).
can you share more information on how to reproduce it? (MinGW version, build env variables, build OS).

Thanks,

Tal.

> Resolved by moving the include of devguid.h after the definition of
> INITGUID.
> 
> Fixes: b762221ac24f ("bus/pci: support Windows with bifurcated drivers")
> Cc: talshn@mellanox.com
> Signed-off-by: Nick Connolly <nick.connolly@mayadata.io>
> ---
>  lib/librte_eal/windows/include/rte_windows.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/librte_eal/windows/include/rte_windows.h
> b/lib/librte_eal/windows/include/rte_windows.h
> index 0a5e71a05..b82af34f6 100644
> --- a/lib/librte_eal/windows/include/rte_windows.h
> +++ b/lib/librte_eal/windows/include/rte_windows.h
> @@ -25,13 +25,13 @@
>  #include <psapi.h>
>  #include <setupapi.h>
>  #include <winioctl.h>
> -#include <devguid.h>
> 
>  /* Have GUIDs defined. */
>  #ifndef INITGUID
>  #define INITGUID
>  #endif
>  #include <initguid.h>
> +#include <devguid.h>
>  #include <rte_log.h>
> 
>  /**
> --
> 2.25.1
  
Nick Connolly Nov. 20, 2020, 11:43 p.m. UTC | #2
> I can't seem to reproduce the link error you've mentioned (I'm building hello_world on master).
> can you share more information on how to reproduce it? (MinGW version, build env variables, build OS).
>
> Thanks,
>
> Tal.

Hi Tal,

Sure - latest MinGW-w64 (v8.0.0 I believe, but the versioning isn't too 
clear to me!).  gcc -v reports:

> C:\Users\Nick>c:\MinGW\mingw64\bin\gcc -v
> Using built-in specs.
> COLLECT_GCC=c:\MinGW\mingw64\bin\gcc
> COLLECT_LTO_WRAPPER=c:/MinGW/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/8.1.0/lto-wrapper.exe
> Target: x86_64-w64-mingw32
> Configured with: ../../../src/gcc-8.1.0/configure 
> --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 
> --target=x86_64-w64-mingw32 --prefix=/mingw64 
> --with-sysroot=/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64 
> --enable-shared --enable-static --disable-multilib 
> --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes 
> --enable-threads=win32 --enable-libgomp --enable-libatomic 
> --enable-lto --enable-graphite --enable-checking=release 
> --enable-fully-dynamic-string --enable-version-specific-runtime-libs 
> --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap 
> --disable-rpath --disable-win32-registry --disable-nls 
> --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld 
> --with-arch=nocona --with-tune=core2 --with-libiconv 
> --with-system-zlib 
> --with-gmp=/c/mingw810/prerequisites/x86_64-w64-mingw32-static 
> --with-mpfr=/c/mingw810/prerequisites/x86_64-w64-mingw32-static 
> --with-mpc=/c/mingw810/prerequisites/x86_64-w64-mingw32-static 
> --with-isl=/c/mingw810/prerequisites/x86_64-w64-mingw32-static 
> --with-pkgversion='x86_64-win32-seh-rev0, Built by MinGW-W64 project' 
> --with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 
> -pipe -fno-ident 
> -I/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/include 
> -I/c/mingw810/prerequisites/x86_64-zlib-static/include 
> -I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' 
> CXXFLAGS='-O2 -pipe -fno-ident 
> -I/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/include 
> -I/c/mingw810/prerequisites/x86_64-zlib-static/include 
> -I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' 
> CPPFLAGS=' 
> -I/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/include 
> -I/c/mingw810/prerequisites/x86_64-zlib-static/include 
> -I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' 
> LDFLAGS='-pipe -fno-ident 
> -L/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/lib 
> -L/c/mingw810/prerequisites/x86_64-zlib-static/lib 
> -L/c/mingw810/prerequisites/x86_64-w64-mingw32-static/lib '
> Thread model: win32
> gcc version 8.1.0 (x86_64-win32-seh-rev0, Built by MinGW-W64 project)

No special build args, just Meson (0.55.3) with --buildtype==debug 
-Dexamples=helloworld

DPDK builds just fine with both MinGW and Clang, but when I try and use 
it to build the SPDK the linking fails with MinGW (but works fine with 
Clang).  The error message is:
> CC app/trace_record/trace_record.o
>   LINK spdk_trace_record.exe
> C:/Users/Nick/Repos/upstream/build/lib/librte_bus_pci.a(bus_pci_windows_pci.c.obj):pci.c:(.rdata$.refptr.GUID_DEVCLASS_NET[.refptr.GUID_DEVCLASS_NET]+0x0): 
> undefined reference to `GUID_DEVCLASS_NET'

As far as I can see this is because the GUID_DEVCLASS_NET structure has 
not been created within the DPDK object files - it requires INITGUID to 
be set when devguid.h is included in order to create a 'select any' 
initialised structure.  Moving devguid.h after defining INITGUID 
resolves the issue.  Arguably, it would perhaps be better to define 
INITGUID in the source files that use the guids instead of in a shared 
header, but I think this can safely be left until after 20.11 is 
finalized - if there's any impact on the code produced it will be 
negligible.

I haven't worked it through but I suspect the reason it's ok with clang 
is because of a difference between the Microsoft headers and those 
shipped with MinGW.

Regards,
Nick
  
Nick Connolly Nov. 20, 2020, 11:44 p.m. UTC | #3
Build OS is Windows 10 2004
  
Dmitry Kozlyuk Nov. 21, 2020, 8:47 p.m. UTC | #4
Hi Nick,

Thanks for detailed explanation. It can be reproduced even without DPDK:

#include <windows.h>
#include <devguid.h>

int
main(int argc, char **argv) {
    return (int)&GUID_DEVCLASS_NET;
}

This links with clang, but not with MinGW-w64. AFAIK, it should not link,
because INITGUID is not defined. @DmitryM, @Naty, correct me if I'm wrong.
So I agree your fix is needed.


> Sure - latest MinGW-w64 (v8.0.0 I believe, but the versioning isn't too 
> clear to me!).

This is correct, MinGW-w64 version is different from GCC version, so it's
MinGW-w64 8.0.0 with GCC 8.1.0.


> [...] Arguably, it would perhaps be better to define 
> INITGUID in the source files that use the guids instead of in a shared 
> header, but I think this can safely be left until after 20.11 is 
> finalized - if there's any impact on the code produced it will be 
> negligible.

I disagree. Just because we have rte_windows.h to properly plug Windows SDK
in, other DPDK code doesn't need to care about these details. Unused GUIDs do
take some space in static libraries, but IMO it's a fair trade for ease of
development. They shouldn't have any impact on resulting binaries.
  
Nick Connolly Nov. 21, 2020, 9:50 p.m. UTC | #5
Hi Dmitry,

On 21/11/2020 20:47, Dmitry Kozlyuk wrote:
> I disagree. Just because we have rte_windows.h to properly plug Windows SDK
> in, other DPDK code doesn't need to care about these details. Unused GUIDs do
> take some space in static libraries, but IMO it's a fair trade for ease of
> development. They shouldn't have any impact on resulting binaries.

Ah!  I hadn't spotted that rte_windows.h is intended to wrap the Windows 
SDK.
In which case, I agree with you - best to take care of it there.

Regards,
Nick
  
Dmitry Kozlyuk Nov. 21, 2020, 10:02 p.m. UTC | #6
On Fri, 20 Nov 2020 21:12:55 +0000, Nick Connolly wrote:
> Linking with the 'pci' driver when building with MinGW on
> Windows fails with undefined symbol 'GUID_DEVCLASS_NET'.
> This occurs because devguid.h is included in rte_windows.h
> before INITGUID is defined.
> 
> Resolved by moving the include of devguid.h after the definition
> of INITGUID.

Commit changes should be described in present tense.

> 
> Fixes: b762221ac24f ("bus/pci: support Windows with bifurcated drivers")
> Cc: talshn@mellanox.com

A blank line should be here.

> Signed-off-by: Nick Connolly <nick.connolly@mayadata.io>
> ---

Apart from those nits,
Acked-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
  

Patch

diff --git a/lib/librte_eal/windows/include/rte_windows.h b/lib/librte_eal/windows/include/rte_windows.h
index 0a5e71a05..b82af34f6 100644
--- a/lib/librte_eal/windows/include/rte_windows.h
+++ b/lib/librte_eal/windows/include/rte_windows.h
@@ -25,13 +25,13 @@ 
 #include <psapi.h>
 #include <setupapi.h>
 #include <winioctl.h>
-#include <devguid.h>
 
 /* Have GUIDs defined. */
 #ifndef INITGUID
 #define INITGUID
 #endif
 #include <initguid.h>
+#include <devguid.h>
 #include <rte_log.h>
 
 /**