openvpn-devel Mailing List for OpenVPN

This is not the a problem when building using the latest Mac OS X SDK. I've did a quick search and it seems to be a more common issue on some (old) Darwin platforms. Please try building again after applying the patch below. Signed-off-by: Frank de Brabander <deb...@gm...> --- socket.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/socket.c b/socket.c index 1a772af..6337900 100644 --- a/socket.c +++ b/socket.c @@ -893,8 +893,13 @@ create_socket_udp6 (const unsigned int flags) else if (flags & SF_USE_IP_PKTINFO) { int pad = 1; +#ifndef IPV6_RECVPKTINFO /* Some older Darwin platforms require this */ + if (setsockopt (sd, IPPROTO_IPV6, IPV6_PKTINFO, + (void*)&pad, sizeof(pad)) < 0) +#else if (setsockopt (sd, IPPROTO_IPV6, IPV6_RECVPKTINFO, (void*)&pad, sizeof(pad)) < 0) +#endif	msg(M_SOCKERR, "UDP: failed setsockopt for IPV6_RECVPKTINFO"); } #endif -- 1.7.5.4 On 22 feb, 15:13, David Sommerseth <ope...@to...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 22/02/12 14:47, Jonathan K. Bullard wrote: > > > > > > > > > > > 2012/2/21 Samuli Seppänen <sa...@op...> > >> ApreviewofOpenVPN2.3-alpha1installerfor Windows isnow > >>availablehere: > > >> <http://build.openvpn.net/downloads/snapshots/openvpn-2.3-alpha1-previ...> > > > I realize that this post was aimed at Windows, but building on OS X > > 10.6.8 (for Tunnelblick) fails with the following: > > > gcc-4.0 -DHAVE_CONFIG_H -I. -I../.. -I../../include  -no-cpp-precomp > > -isysroot /Developer/SDKs/MacOSX10.4u.sdk -Os > > -mmacosx-version-min=10.4 -arch i386 -c socket.c In file included from > > buffer.h:29, from socket.h:28, from socket.c:33: error.h:172:5: > > warning: #warning this compiler appears to lack vararg macros which > > will cause a significant degradation in efficiency (you can ignore > > this warning if you are using LCLINT) > > This I don't understand, as this isn't exactly new code.  The warning in > error.h:172 has been in the source tree since September 2005.  I suspect > this to be somehow compiler related. > > I'm compilingOpenVPNregularly on Fedora 14, which uses: > >   $ gcc --version >   gcc (GCC) 4.5.120100924 (Red Hat 4.5.1-4) > > > socket.c: In function 'create_socket_udp6': socket.c:902: error: > > 'IPV6_RECVPKTINFO' undeclared (first use in this function) > > socket.c:902: error: (Each undeclared identifier is reported only > > once socket.c:902: error: for each function it appears in.) make[4]: > > *** [socket.o] Error1 > > This seems to be the main reason why it chokes.  I've Cc'ed Juan Jo, who > introduced this change.  It's related to the new IPv6 transport feature. > > JJO: Can you please see if you can figure out this? > > > The error is the main problem, of course, but I'm not sure what to > > make of the warning, which appears in the compilation of (almost?) > > all modules  -- it's hard to believe that gcc 4.0 doesn't have vararg > > macros, since they are a feature of GNU C! > > Agreed, there is something odd going on here.  But I don't have any OSX > boxesavailableand lack some knowledge about the OSX build environment, > so it's really hard to figure out immediately.  I hope others with OSX > can have a look at what's causing this. > > kind regards, > > David Sommerseth > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > iEYEARECAAYFAk9E9/YACgkQDC186MBRfrrUdgCbB3IL4kKjMgryggfqSwhjcKap > wF4AoKR6WXY9dp/SEBFZS8wow/tPv49L > =w4Eu > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------------- --- > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service.http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________Openvpn-devel mailing lis...@li...://lists.sourceforge.net/lists/listinfo/openvpn-devel 

Hello, in May 2009 James committed in 423037e9fbdff7209ca6f305b812a9908a0f4d13 "Reduce the debug level (--verb) at which received management interface commands are echoed from 7 to 3." A search for comments or a reason did not reveal more informarion. I use the management extensively and these regular management commands bloat the log at the default --verb 3 with at least 3 lines (enter/command/exit). I do not wish to start a debate if this is reasonable or not. The fact, that this #define is still amongst verb 7 defines in the code raises the feeling, that this has simply been forgotten. If this is true, you can use the attached patch, that tosses this single (!) bit. :-) -- Servus Michael 

BTW: I like the mingw implementation, much simpler. It uses the GetSystemTimeAsFileTime() API not performance counters. On Wed, Feb 22, 2012 at 8:46 PM, Alon Bar-Lev <alo...@gm...> wrote: > For all who cannot build and have access to Windows machine. > Please run binary[1] and send output. > > [1] https://github.com/downloads/alonbl/openvpn/timebench.exe > > On Wed, Feb 22, 2012 at 6:12 PM, Alon Bar-Lev <alo...@gm...> wrote: >> Hello all, >> >> There is an abnormality in the openvpn sources I want to resolve. >> >> In windows there is own implementation of gettimeofday(). >> In the past there was no gettimeofday(), so we used performance counters, >> then James optimize it to reduce CPU consumption. >> >> Unlike in the past, mingw does provide this function these days. >> The question is if it is good enough. >> >> There is also a note: >> /* on WIN32, gettimeofday is faster than time(NULL) */ >> >> I am not sure about any of these, can you please try to run the >> benchmark and report back the results? >> It must be compiled using mingw, either at cygwin or at linux. >> >> Thanks, >> Alon 

For all who cannot build and have access to Windows machine. Please run binary[1] and send output. [1] https://github.com/downloads/alonbl/openvpn/timebench.exe On Wed, Feb 22, 2012 at 6:12 PM, Alon Bar-Lev <alo...@gm...> wrote: > Hello all, > > There is an abnormality in the openvpn sources I want to resolve. > > In windows there is own implementation of gettimeofday(). > In the past there was no gettimeofday(), so we used performance counters, > then James optimize it to reduce CPU consumption. > > Unlike in the past, mingw does provide this function these days. > The question is if it is good enough. > > There is also a note: > /* on WIN32, gettimeofday is faster than time(NULL) */ > > I am not sure about any of these, can you please try to run the > benchmark and report back the results? > It must be compiled using mingw, either at cygwin or at linux. > > Thanks, > Alon 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/02/12 17:46, David Sommerseth wrote: > On 22/02/12 17:13, Alon Bar-Lev wrote: >> Dear project managers. I need a decision regarding the minimum >> supported openssl. > > I'd say we support these libraries and tools as the oldest supported: > >> =autoconf-2.59 =automake-1.9 =libtool-1.5.22 =lzo-2.02 >> =openssl-0.9.8 =pkcs11-helper-1.07 (Thank you Thunderbird for screwing up my mail!) Hopefully this passes through without any issues * >=autoconf-2.59 * >=automake-1.9 * >=libtool-1.5.22 * >=lzo-2.02 * >=openssl-0.9.8 * >=pkcs11-helper-1.07 > This covers RHEL5 environments easily. > > James: RHEL4 support officially ends in 6 days from Red Hat. I'm > here proposing to kill RHEL4 support, and have RHEL5 support as the > minimum. If people want to be stuck on RHEL4, they're stuck with > OpenVPN 2.2 and older. > > I would even say that if nobody rejects this idea within the next 72 > hours, then it is decided. If James can reply and give it an ACK, it > will be valid instantly. > > Is that fine with everyone? kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9FHNwACgkQDC186MBRfrpa4gCglUZuoEbnt1rKHUpxqkBW+Cmg Ss4AoITDMPQCB/dcclG/DN0fMoGOxSDt =7bQC -----END PGP SIGNATURE----- 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/02/12 17:40, Alon Bar-Lev wrote: > On Wed, Feb 22, 2012 at 6:37 PM, David Sommerseth > <ope...@to...> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 22/02/12 17:27, Heiko Hund wrote: >>> On Wednesday 22 February 2012 16:12:24 Alon Bar-Lev wrote: >>>> In windows there is own implementation of gettimeofday(). In >>>> the past there was no gettimeofday(), so we used performance >>>> counters, then James optimize it to reduce CPU consumption. >>>> >>>> Unlike in the past, mingw does provide this function these days. >>>> The question is if it is good enough. >>> >>> Since there's no gettimeofday() in MSVC this will break building >>> with the python build system. Not sure if we're in the process of >>> getting rid of it, which I would welcome, so this is just for >>> additional information. >> >> That's a valid point ... But it makes me think. What about to put >> James' old code in compat.[ch] for platforms without gettimeofday. >> Would that be an appropriate middle-road? >> >> I too would like to see MSVC go away. Very much. But again, let's >> not decide that without James approval for it. > > Again, There is nothing written about not supporting the proprietary > gettimeofday implementation in MSVC. What exactly is the problem? You > compile on *NIX you get system gettimeofday. You compile on mingw you > get library gettimeofday. You compile on msvc you get own > implementation. > > Wasn't I clear? Sorry, I saw your reply to Heiko too late. That response was more than clear enough. Disregard my comment, my single-threaded workflow doesn't scale too well :) kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9FHFkACgkQDC186MBRfro+IQCgpRzrvNnW7VguHtMaO+E86COq euoAoIkgx4tS5GJszE2ZZG9zHfTnREuL =bnqZ -----END PGP SIGNATURE----- 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/02/12 17:13, Alon Bar-Lev wrote: > Dear project managers. I need a decision regarding the minimum > supported openssl. I'd say we support these libraries and tools as the oldest supported: > =autoconf-2.59 =automake-1.9 =libtool-1.5.22 =lzo-2.02 =openssl-0.9.8 > =pkcs11-helper-1.07 This covers RHEL5 environments easily. James: RHEL4 support officially ends in 6 days from Red Hat. I'm here proposing to kill RHEL4 support, and have RHEL5 support as the minimum. If people want to be stuck on RHEL4, they're stuck with OpenVPN 2.2 and older. I would even say that if nobody rejects this idea within the next 72 hours, then it is decided. If James can reply and give it an ACK, it will be valid instantly. Is that fine with everyone? kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9FG9EACgkQDC186MBRfrrozQCbBg6I2Tzm3SwV1sTJn1cMUebS sAcAn2btP5D10ChDNZGSywqbEebzonRQ =q7wE -----END PGP SIGNATURE----- 

On Wed, Feb 22, 2012 at 6:37 PM, David Sommerseth <ope...@to...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 22/02/12 17:27, Heiko Hund wrote: >> On Wednesday 22 February 2012 16:12:24 Alon Bar-Lev wrote: >>> In windows there is own implementation of gettimeofday(). In the >>> past there was no gettimeofday(), so we used performance counters, >>> then James optimize it to reduce CPU consumption. >>> >>> Unlike in the past, mingw does provide this function these days. The >>> question is if it is good enough. >> >> Since there's no gettimeofday() in MSVC this will break building with >> the python build system. Not sure if we're in the process of getting >> rid of it, which I would welcome, so this is just for additional >> information. > > That's a valid point ... But it makes me think.  What about to put James' > old code in compat.[ch] for platforms without gettimeofday.  Would that > be an appropriate middle-road? > > I too would like to see MSVC go away.  Very much.  But again, let's not > decide that without James approval for it. Again, There is nothing written about not supporting the proprietary gettimeofday implementation in MSVC. What exactly is the problem? You compile on *NIX you get system gettimeofday. You compile on mingw you get library gettimeofday. You compile on msvc you get own implementation. Wasn't I clear? Alon. 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/02/12 17:27, Heiko Hund wrote: > On Wednesday 22 February 2012 16:12:24 Alon Bar-Lev wrote: >> In windows there is own implementation of gettimeofday(). In the >> past there was no gettimeofday(), so we used performance counters, >> then James optimize it to reduce CPU consumption. >> >> Unlike in the past, mingw does provide this function these days. The >> question is if it is good enough. > > Since there's no gettimeofday() in MSVC this will break building with > the python build system. Not sure if we're in the process of getting > rid of it, which I would welcome, so this is just for additional > information. That's a valid point ... But it makes me think. What about to put James' old code in compat.[ch] for platforms without gettimeofday. Would that be an appropriate middle-road? I too would like to see MSVC go away. Very much. But again, let's not decide that without James approval for it. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9FGd0ACgkQDC186MBRfrp4SQCeKnZFdeJpLz4SCxfVmKr+Ffmv 2HYAn3/sVVgjonZ/HBh+axoXTF1s+At8 =MIxf -----END PGP SIGNATURE----- 

On Wed, Feb 22, 2012 at 6:27 PM, Heiko Hund <hei...@so...> wrote: > Since there's no gettimeofday() in MSVC this will break building with the > python build system. Not sure if we're in the process of getting rid of it, > which I would welcome, so this is just for additional information. The python build system will be replaced with my work. Anyway, I did not write that in MSVC the windows implementation will be removed. Just want to know if indeed the time(NULL) is slower and if we can use standard gettimeofday in mingw. Alon. 

On Wednesday 22 February 2012 16:12:24 Alon Bar-Lev wrote: > In windows there is own implementation of gettimeofday(). > In the past there was no gettimeofday(), so we used performance counters, > then James optimize it to reduce CPU consumption. > > Unlike in the past, mingw does provide this function these days. > The question is if it is good enough. Since there's no gettimeofday() in MSVC this will break building with the python build system. Not sure if we're in the process of getting rid of it, which I would welcome, so this is just for additional information. Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen 

Hi Alon, Alon Bar-Lev wrote: > Hello all, > > There is an abnormality in the openvpn sources I want to resolve. > > In windows there is own implementation of gettimeofday(). > In the past there was no gettimeofday(), so we used performance counters, > then James optimize it to reduce CPU consumption. > > Unlike in the past, mingw does provide this function these days. > The question is if it is good enough. > > There is also a note: > /* on WIN32, gettimeofday is faster than time(NULL) */ > > I am not sure about any of these, can you please try to run the > benchmark and report back the results? > It must be compiled using mingw, either at cygwin or at linux. > > First: $ i686-pc-mingw32-gcc -o timebench.exe timebench.c In a virtual WinXP SP3 env on my 2.50 GHz Intel T9300: c:\users\janjust>timebench.exe time(): 18 gettimeofday(): 47 openvpn_gettimeofday(): 16 share and enjoy, JJK 

Dear project managers. I need a decision regarding the minimum supported openssl. 

Hello all, There is an abnormality in the openvpn sources I want to resolve. In windows there is own implementation of gettimeofday(). In the past there was no gettimeofday(), so we used performance counters, then James optimize it to reduce CPU consumption. Unlike in the past, mingw does provide this function these days. The question is if it is good enough. There is also a note: /* on WIN32, gettimeofday is faster than time(NULL) */ I am not sure about any of these, can you please try to run the benchmark and report back the results? It must be compiled using mingw, either at cygwin or at linux. Thanks, Alon 

Hi Jonathan, This does not really address the issue you're having, but could you try if using Alon's new buildsystem helps: <https://github.com/alonbl/openvpn/downloads> You need to copy the "generic" directory to OpenVPN source directory, cd to it and do a ./build. There's some additional info in the README file. I used it earlier today successfully to compile native + 32/64-bit Windows binaries on Ubuntu 11.10. It should also work fine on MacOS X if all dependencies are in place: <http://thread.gmane.org/gmane.network.openvpn.devel/5527> Samuli >> A preview of OpenVPN 2.3-alpha1 installer for Windows is now available >> here: >> >> <http://build.openvpn.net/downloads/snapshots/openvpn-2.3-alpha1-preview1-install.exe> > I realize that this post was aimed at Windows, but building on OS X > 10.6.8 (for Tunnelblick) fails with the following: > > gcc-4.0 -DHAVE_CONFIG_H -I. -I../.. -I../../include -no-cpp-precomp > -isysroot /Developer/SDKs/MacOSX10.4u.sdk -Os > -mmacosx-version-min=10.4 -arch i386 -c socket.c > In file included from buffer.h:29, > from socket.h:28, > from socket.c:33: > error.h:172:5: warning: #warning this compiler appears to lack vararg > macros which will cause a significant degradation in efficiency (you > can ignore this warning if you are using LCLINT) > socket.c: In function 'create_socket_udp6': > socket.c:902: error: 'IPV6_RECVPKTINFO' undeclared (first use in this function) > socket.c:902: error: (Each undeclared identifier is reported only once > socket.c:902: error: for each function it appears in.) > make[4]: *** [socket.o] Error 1 > > The error is the main problem, of course, but I'm not sure what to > make of the warning, which appears in the compilation of (almost?) all > modules -- it's hard to believe that gcc 4.0 doesn't have vararg > macros, since they are a feature of GNU C! > > The full compilation log is available at http://pastebin.com/DaPnQZCH 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/02/12 14:47, Jonathan K. Bullard wrote: > 2012/2/21 Samuli Seppänen <sa...@op...> >> A preview of OpenVPN 2.3-alpha1 installer for Windows is now >> available here: >> >> <http://build.openvpn.net/downloads/snapshots/openvpn-2.3-alpha1-preview1-install.exe> > >> > I realize that this post was aimed at Windows, but building on OS X > 10.6.8 (for Tunnelblick) fails with the following: > > gcc-4.0 -DHAVE_CONFIG_H -I. -I../.. -I../../include -no-cpp-precomp > -isysroot /Developer/SDKs/MacOSX10.4u.sdk -Os > -mmacosx-version-min=10.4 -arch i386 -c socket.c In file included from > buffer.h:29, from socket.h:28, from socket.c:33: error.h:172:5: > warning: #warning this compiler appears to lack vararg macros which > will cause a significant degradation in efficiency (you can ignore > this warning if you are using LCLINT) This I don't understand, as this isn't exactly new code. The warning in error.h:172 has been in the source tree since September 2005. I suspect this to be somehow compiler related. I'm compiling OpenVPN regularly on Fedora 14, which uses: $ gcc --version gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) > socket.c: In function 'create_socket_udp6': socket.c:902: error: > 'IPV6_RECVPKTINFO' undeclared (first use in this function) > socket.c:902: error: (Each undeclared identifier is reported only > once socket.c:902: error: for each function it appears in.) make[4]: > *** [socket.o] Error 1 This seems to be the main reason why it chokes. I've Cc'ed Juan Jo, who introduced this change. It's related to the new IPv6 transport feature. JJO: Can you please see if you can figure out this? > The error is the main problem, of course, but I'm not sure what to > make of the warning, which appears in the compilation of (almost?) > all modules -- it's hard to believe that gcc 4.0 doesn't have vararg > macros, since they are a feature of GNU C! Agreed, there is something odd going on here. But I don't have any OSX boxes available and lack some knowledge about the OSX build environment, so it's really hard to figure out immediately. I hope others with OSX can have a look at what's causing this. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9E9/YACgkQDC186MBRfrrUdgCbB3IL4kKjMgryggfqSwhjcKap wF4AoKR6WXY9dp/SEBFZS8wow/tPv49L =w4Eu -----END PGP SIGNATURE----- 

2012/2/21 Samuli Seppänen <sa...@op...> > A preview of OpenVPN 2.3-alpha1 installer for Windows is now available > here: > > <http://build.openvpn.net/downloads/snapshots/openvpn-2.3-alpha1-preview1-install.exe> I realize that this post was aimed at Windows, but building on OS X 10.6.8 (for Tunnelblick) fails with the following: gcc-4.0 -DHAVE_CONFIG_H -I. -I../.. -I../../include -no-cpp-precomp -isysroot /Developer/SDKs/MacOSX10.4u.sdk -Os -mmacosx-version-min=10.4 -arch i386 -c socket.c In file included from buffer.h:29, from socket.h:28, from socket.c:33: error.h:172:5: warning: #warning this compiler appears to lack vararg macros which will cause a significant degradation in efficiency (you can ignore this warning if you are using LCLINT) socket.c: In function 'create_socket_udp6': socket.c:902: error: 'IPV6_RECVPKTINFO' undeclared (first use in this function) socket.c:902: error: (Each undeclared identifier is reported only once socket.c:902: error: for each function it appears in.) make[4]: *** [socket.o] Error 1 The error is the main problem, of course, but I'm not sure what to make of the warning, which appears in the compilation of (almost?) all modules -- it's hard to believe that gcc 4.0 doesn't have vararg macros, since they are a feature of GNU C! The full compilation log is available at http://pastebin.com/DaPnQZCH 

On Wed, Feb 22, 2012 at 12:36 PM, Heiko Hund <hei...@so...> wrote: > On Wednesday 22 February 2012 10:32:23 Alon Bar-Lev wrote: >> On Wed, Feb 22, 2012 at 12:27 PM, Heiko Hund <hei...@so...> wrote: >> > I was cross compiling for Windows previously doing something very >> > standard >> > like `./configure --host=i686-w64-mingw32 ...` followed by `make`. What >> > the rationale behind moving away from this way? >> >> This is exactly what this build is doing. >> Just it also builds the dependencies and package the output. >> The most difficult task (usually) is to compile the dependencies. > > What dependencies do you mean? lzo, openssl and pkcs11-helper? Right. Look at the script. 

On Wednesday 22 February 2012 10:32:23 Alon Bar-Lev wrote: > On Wed, Feb 22, 2012 at 12:27 PM, Heiko Hund <hei...@so...> wrote: > > I was cross compiling for Windows previously doing something very > > standard > > like `./configure --host=i686-w64-mingw32 ...` followed by `make`. What > > the rationale behind moving away from this way? > > This is exactly what this build is doing. > Just it also builds the dependencies and package the output. > The most difficult task (usually) is to compile the dependencies. What dependencies do you mean? lzo, openssl and pkcs11-helper? Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen 

BTW: cross compile support was added by me to OpenVPN long time ago. It is just that I've done the minimum required changes back-then. I needed this for OpenSC users, to be able to compile OpenSC and OpenVPN with the same version of OpenSSL. On Wed, Feb 22, 2012 at 12:32 PM, Alon Bar-Lev <alo...@gm...> wrote: > On Wed, Feb 22, 2012 at 12:27 PM, Heiko Hund <hei...@so...> wrote: >> I was cross compiling for Windows previously doing something very standard >> like `./configure --host=i686-w64-mingw32 ...` followed by `make`. What the >> rationale behind moving away from this way? > > This is exactly what this build is doing. > Just it also builds the dependencies and package the output. > The most difficult task (usually) is to compile the dependencies. > > Alon. 

On Wed, Feb 22, 2012 at 12:27 PM, Heiko Hund <hei...@so...> wrote: > I was cross compiling for Windows previously doing something very standard > like `./configure --host=i686-w64-mingw32 ...` followed by `make`. What the > rationale behind moving away from this way? This is exactly what this build is doing. Just it also builds the dependencies and package the output. The most difficult task (usually) is to compile the dependencies. Alon. 

On Wednesday 22 February 2012 00:12:25 Alon Bar-Lev wrote: > BEST METHOD - Compile on Linux > > This is a generic method, it can cross compile OpenVPN using any > toolchain to any environment. > For Windows, make sure you have mingw-w64 toolchain. > We are using nsis so we can also package files at Linux. > > $ cd generic > $ IMAGEROOT=`pwd`/image-win32 CHOST=i686-w64-mingw32 > CBUILD=x86_64-pc-linux-gnu ./build > $ IMAGEROOT=`pwd`/image-win64 CHOST=x86_64-w64-mingw32 > CBUILD=x86_64-pc-linux-gnu ./build I was cross compiling for Windows previously doing something very standard like `./configure --host=i686-w64-mingw32 ...` followed by `make`. What the rationale behind moving away from this way? Heiko -- Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200 Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe Represented by the General Partner Astaro Verwaltungs GmbH Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen, Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen 

Hi all, Thanks to Alon Bar-Lev we now have a buildsystem that also allows, among other things, cross-compiling Windows binaries on *NIX platforms. I built two sets of binaries for testing purposes and they seemed to work just fine on both Windows XP (32-bit) and Windows 7 (64-bit). However, more testing never hurts, so any test reports are appreciated! The binaries are available here: <http://build.openvpn.net/downloads/snapshots/bin32.zip> <http://build.openvpn.net/downloads/snapshots/bin64.zip> You need to install OpenVPN as usual first. Then you just replace it's "bin" directory[1] with the one contained in the zip-file. NOTE: the included openvpn.exe does not support loading passwords from a file. -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock [1] Usually "C:\Program Files\OpenVPN\bin" or "C:\Program Files (x86)\OpenVPN\bin" 

2012/2/22 Samuli Seppänen <sa...@op...>: > I used this method to cross-compile for Windows (32-bit and 64-bit) on > Ubuntu 11.10 amd64. I replaced the "bin" directory of an existing > openvpn-2.3-alpha1 installation with the results on a 32-bit WinXP box > and it seemed work ok. Thank you for testing! > > Anyways, there was a problem with permissions during build: > > --- snip --- > Fixup libtool files > Restore libtool files > Copying documents > Copying sources > Cleaning empty directories > x86_64-w64-mingw32-strip: unable to copy file > '/home/samuli/opt/openvpn/generic/image > -win64/openvpn/lib/engines/gmpeay32.dll'; reason: Permission denied > x86_64-w64-mingw32-strip: unable to copy file > '/home/samuli/opt/openvpn/generic/image-win64/openvpn/lib/engines/atallaeay32.dll'; > reason: Permission denied > --- snip --- > > The offending files had 555 permissions. Changing them manually to 755 > and restarting the build from correct phase allowed the build to complete. Oh... these warnings can be safely ignored. Alon. 

Hi, On Wed, Feb 22, 2012 at 10:57:43AM +0200, Alon Bar-Lev wrote: > > On Wed, Feb 22, 2012 at 10:04:51AM +0200, Samuli Seppänen wrote: > >> > While you at it, please try to explain me why we need Visual Studio build... :) [..] > > We have Visual Studio because James was afraid that mingw would stop > > being supported, leaving us without a viable build environment.  Which > > turns out to be not a real problem (yet), given that mingw64 seems to > > be supported quite well. > > I never knew this is the reason. And I follow this project for long time. James said so on IRC (and there was a subsequent discussion about this on the mailing list, when the IRC meeting notes were posted - about 1.5 years ago). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne...