| Message ID | 20200205124615.15758-3-domagoj@pensa.hr |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Couple of fixes | expand |
Hi, On Wed, Feb 05, 2020 at 01:46:15PM +0100, Domagoj Pensa wrote: > MinGW linking fails for several files due to a missing "static" > declaration in functions tuntap_is_wintun() and tuntap_ring_empty(). It does not fail for us. So what MinGW version on what OS are you using to exhibit this error? (The change might still make sense, but the explanation does not make much sense - exporting a function which is not needed "outside" should never cause a link fail) gert
Hi! On Wed, Feb 05, 2020 at 02:05:11PM +0100, Gert Doering wrote: > Hi, > > On Wed, Feb 05, 2020 at 01:46:15PM +0100, Domagoj Pensa wrote: > > MinGW linking fails for several files due to a missing "static" > > declaration in functions tuntap_is_wintun() and tuntap_ring_empty(). > > It does not fail for us. So what MinGW version on what OS are you using > to exhibit this error? I've mentioned that in first mail: I'm using Ubuntu 19.04 with mingw-w64 from official repository (version 6.0.0-3) and for build process script generic/build from openvpn-build repository. I've also included linker output same mail: /usr/bin/x86_64-w64-mingw32-ld: forward.o:forward.c:(.text+0x5fec): undefined reference to `tuntap_is_wintun' /usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x8a4): undefined reference to `tuntap_is_wintun' /usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x1362): undefined reference to `tuntap_is_wintun' /usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x1379): undefined reference to `tuntap_ring_empty' /usr/bin/x86_64-w64-mingw32-ld: mudp.o:mudp.c:(.text+0x536): undefined reference to `tuntap_is_wintun' /usr/bin/x86_64-w64-mingw32-ld: mudp.o:mudp.c:(.text+0xf53): undefined reference to `tuntap_ring_empty' /usr/bin/x86_64-w64-mingw32-ld: openvpn.o:openvpn.c:(.text+0x1b6): undefined reference to `tuntap_ring_empty' /usr/bin/x86_64-w64-mingw32-ld: openvpn.o:openvpn.c:(.text+0x261): undefined reference to `tuntap_is_wintun' collect2: error: ld returned 1 exit status Here are versions for some tools from that package: $ /usr/bin/x86_64-w64-mingw32-ld -v GNU ld (GNU Binutils) 2.32 $ x86_64-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/lto-wrapper Target: x86_64-w64-mingw32 Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --with-headers=/usr/x86_64-w64-mingw32/include --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto --with-plugin-ld --enable-threads=win32 --program-suffix=-win32 --program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 --with-as=/usr/bin/x86_64-w64-mingw32-as --with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic Thread model: win32 gcc version 8.3-win32 20190406 (GCC) Domagoj
Hi! On Wed, Feb 05, 2020 at 02:05:11PM +0100, Gert Doering wrote: > Hi, > > On Wed, Feb 05, 2020 at 01:46:15PM +0100, Domagoj Pensa wrote: > > MinGW linking fails for several files due to a missing "static" > > declaration in functions tuntap_is_wintun() and tuntap_ring_empty(). > > It does not fail for us. So what MinGW version on what OS are you using > to exhibit this error? I've mentioned that in first mail: I'm using Ubuntu 19.04 with mingw-w64 from official repository (version 6.0.0-3) and for build process script generic/build from openvpn-build repository. I've also included linker output same mail: /usr/bin/x86_64-w64-mingw32-ld: forward.o:forward.c:(.text+0x5fec): undefined reference to `tuntap_is_wintun' /usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x8a4): undefined reference to `tuntap_is_wintun' /usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x1362): undefined reference to `tuntap_is_wintun' /usr/bin/x86_64-w64-mingw32-ld: mtcp.o:mtcp.c:(.text+0x1379): undefined reference to `tuntap_ring_empty' /usr/bin/x86_64-w64-mingw32-ld: mudp.o:mudp.c:(.text+0x536): undefined reference to `tuntap_is_wintun' /usr/bin/x86_64-w64-mingw32-ld: mudp.o:mudp.c:(.text+0xf53): undefined reference to `tuntap_ring_empty' /usr/bin/x86_64-w64-mingw32-ld: openvpn.o:openvpn.c:(.text+0x1b6): undefined reference to `tuntap_ring_empty' /usr/bin/x86_64-w64-mingw32-ld: openvpn.o:openvpn.c:(.text+0x261): undefined reference to `tuntap_is_wintun' collect2: error: ld returned 1 exit status Here are versions for some tools from that package: $ /usr/bin/x86_64-w64-mingw32-ld -v GNU ld (GNU Binutils) 2.32 $ x86_64-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/lto-wrapper Target: x86_64-w64-mingw32 Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --with-headers=/usr/x86_64-w64-mingw32/include --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto --with-plugin-ld --enable-threads=win32 --program-suffix=-win32 --program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 --with-as=/usr/bin/x86_64-w64-mingw32-as --with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic Thread model: win32 gcc version 8.3-win32 20190406 (GCC) Domagoj
---------- Forwarded message --------- From: Selva Nair <selva.nair@gmail.com> Date: Wed, Feb 5, 2020 at 10:16 AM Subject: Re: [Openvpn-devel] [PATCH 2/2] Fix linking issues on MinGW To: Domagoj Pensa <domagoj@pensa.hr> Cc: Gert Doering <gert@greenie.muc.de> Hi, On Wed, Feb 5, 2020 at 8:31 AM Domagoj Pensa <domagoj@pensa.hr> wrote: > > Hi! > > On Wed, Feb 05, 2020 at 02:05:11PM +0100, Gert Doering wrote: > > Hi, > > > > On Wed, Feb 05, 2020 at 01:46:15PM +0100, Domagoj Pensa wrote: > > > MinGW linking fails for several files due to a missing "static" > > > declaration in functions tuntap_is_wintun() and tuntap_ring_empty(). > > > > Are you building without optimization? Please try using the latest openvpn-build (or just add -O2 to complier options). I suspect this is caused by the fact that gcc does not inline when optimization is not on, but also not generating exported code in that case. Inline implementation in gcc has so many subtleties, so not sure whether this is a compiler bug or "feature". Adding a static appears to be not a bad solution as gcc will emit external code for static inline functions only if necessary. Selva
Hi, On Wed, Feb 05, 2020 at 10:28:38AM -0500, Selva Nair wrote: > Are you building without optimization? Please try using the latest > openvpn-build (or just add -O2 to complier options). Yes, that was it! When Lev said that he doesn't have problems with build, I've noticed that he is using script build-complete from windows-nsis. I didn't want installer build, just binaries, so I followed instructions from README and generic/README and thus I used generic/build. But that doesn't include -O2 and I get mentioned error when linking. In windows-nsis/build-complete there are additional flags "-O2 -flto" and that's why Lev doesn't have issues and we are using same tools and OS versions. Those additional flags where added by Lev in commit 3eb61bb in openvpn-build. Problem solved, now I know for the future. But still it would be nice to somehow "fix" this for others, by either updating READMEs, adding -O2 to generic/build script or apply patch I've sent that helped me and links with optimization off. Maybe doing all that won't be bad. Thank you all! Domagoj
Hi, Good catch. "Inline" generates inline definition and if we don't do inlining (by not specifying O2), linker doesn't see it and prints an error. Apparently MSVC is lax on that. Checking source code, most (if all?) or inline methods are static. Obviously we want our code to compile without O2, so ACK from me. Acked-by: Lev Stipakov <lstipakov@gmail.com> ke 5. helmik. 2020 klo 17.41 Domagoj Pensa (domagoj@pensa.hr) kirjoitti: > Hi, > > On Wed, Feb 05, 2020 at 10:28:38AM -0500, Selva Nair wrote: > > Are you building without optimization? Please try using the latest > > openvpn-build (or just add -O2 to complier options). > > Yes, that was it! > > When Lev said that he doesn't have problems with build, I've noticed that > he > is using script build-complete from windows-nsis. > > I didn't want installer build, just binaries, so I followed instructions > from README and generic/README and thus I used generic/build. > > But that doesn't include -O2 and I get mentioned error when linking. > > In windows-nsis/build-complete there are additional flags "-O2 -flto" and > that's why Lev doesn't have issues and we are using same tools and OS > versions. > > Those additional flags where added by Lev in commit 3eb61bb in > openvpn-build. > > Problem solved, now I know for the future. > > But still it would be nice to somehow "fix" this for others, by either > updating READMEs, adding -O2 to generic/build script or apply patch I've > sent that helped me and links with optimization off. > > Maybe doing all that won't be bad. > > Thank you all! > > Domagoj > > > _______________________________________________ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
Your patch has been applied to the master branch.
I have slightly modified the commit message to explain the underlying
issue better ("if compiled without -O2"). No change code-wise to your
patch. Makes sense :-)
commit 5822e52c6b0f86f9e4de946f9fb1374c6fad95f1
Author: Domagoj Pensa
Date: Wed Feb 5 13:46:15 2020 +0100
Fix linking issues on MinGW
Signed-off-by: Domagoj Pensa <domagoj@pensa.hr>
Acked-by: Lev Stipakov <lstipakov@gmail.com>
Message-Id: <20200205124615.15758-3-domagoj@pensa.hr>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg19356.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
--
kind regards,
Gert Doering
diff --git a/src/openvpn/tun.h b/src/openvpn/tun.h index 97d28f45..327d7927 100644 --- a/src/openvpn/tun.h +++ b/src/openvpn/tun.h @@ -224,13 +224,13 @@ tuntap_defined(const struct tuntap *tt) } #ifdef _WIN32 -inline bool +static inline bool tuntap_is_wintun(struct tuntap *tt) { return tt && tt->windows_driver == WINDOWS_DRIVER_WINTUN; } -inline bool +static inline bool tuntap_ring_empty(struct tuntap *tt) { return tuntap_is_wintun(tt) && (tt->wintun_send_ring->head == tt->wintun_send_ring->tail);
MinGW linking fails for several files due to a missing "static" declaration in functions tuntap_is_wintun() and tuntap_ring_empty(). Signed-off-by: Domagoj Pensa <domagoj@pensa.hr> --- src/openvpn/tun.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)