Re: [Openvpn-devel] OpenVPN 2.3-alpha1 preview 1 installer now available

[debrabander]

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 
---
 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 
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 22/02/12 14:47, Jonathan K. Bullard wrote:
>
>
>
>
>
>
>
>
>
> > 2012/2/21 Samuli Seppänen 
> >> ApreviewofOpenVPN2.3-alpha1installerfor Windows isnow
> >>availablehere:
>
> >> 
>
> > 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 
> listOpenvpn-de...@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Log level of management interface: patch from 2009

[Michael Kress]

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
>From 78e3853622fe41f4aa638e887f5fd4f064be6c07 Mon Sep 17 00:00:00 2001
From: Michael Kress 
List-Post: openvpn-devel@lists.sourceforge.net
Date: Wed, 22 Feb 2012 19:50:45 +0100
Subject: [PATCH] Increase the debug level (--verb) at which received management
 interface commands are echoed from 3 to 7.

Signed-off-by: Michael Kress 
---
 errlevel.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/errlevel.h b/errlevel.h
index 74729c9..726f0b3 100644
--- a/errlevel.h
+++ b/errlevel.h
@@ -133,7 +133,7 @@
 #define D_SEMAPHORE_LOW  LOGLEV(7, 70, M_DEBUG)  /* show Win32 semaphore waits (low freq) */
 #define D_SEMAPHORE  LOGLEV(7, 70, M_DEBUG)  /* show Win32 semaphore waits */
 #define D_TEST_FILE  LOGLEV(7, 70, M_DEBUG)  /* show test_file() calls */
-#define D_MANAGEMENT_DEBUG   LOGLEV(3, 70, M_DEBUG)  /* show --management debug info */
+#define D_MANAGEMENT_DEBUG   LOGLEV(7, 70, M_DEBUG)  /* show --management debug info */
 #define D_PLUGIN_DEBUG   LOGLEV(7, 70, M_DEBUG)  /* show verbose plugin calls */
 #define D_SOCKET_DEBUG   LOGLEV(7, 70, M_DEBUG)  /* show socket.[ch] debugging info */
 #define D_SHOW_PKCS11LOGLEV(7, 70, M_DEBUG)  /* show PKCS#11 actions */
-- 
1.7.3.4

Re: [Openvpn-devel] [RFC][windows] gettimeofday()

[Alon Bar-Lev]

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  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  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

Re: [Openvpn-devel] [RFC][windows] gettimeofday()

[Alon Bar-Lev]

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  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

Re: [Openvpn-devel] [RFC] openssl minimum supported version

[David Sommerseth]

-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-

Re: [Openvpn-devel] [RFC][windows] gettimeofday()

[David Sommerseth]

-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 
>  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-

Re: [Openvpn-devel] [RFC] openssl minimum supported version

[David Sommerseth]

-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-

Re: [Openvpn-devel] [RFC][windows] gettimeofday()

[Alon Bar-Lev]

On Wed, Feb 22, 2012 at 6:37 PM, David Sommerseth
 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.

Re: [Openvpn-devel] [RFC][windows] gettimeofday()

[David Sommerseth]

-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-

Re: [Openvpn-devel] [RFC][windows] gettimeofday()

[Alon Bar-Lev]

On Wed, Feb 22, 2012 at 6:27 PM, Heiko Hund  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.

Re: [Openvpn-devel] [RFC][windows] gettimeofday()

[Heiko Hund]

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

Re: [Openvpn-devel] [RFC][windows] gettimeofday()

[Jan Just Keijser]

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

Re: [Openvpn-devel] [RFC] openssl minimum supported version

[Alon Bar-Lev]

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

[Openvpn-devel] [RFC][windows] gettimeofday()

[Alon Bar-Lev]

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
#include 
#include 
#include 

static time_t gtc_base = 0;
static DWORD gtc_last = 0;
static time_t last_sec = 0;
static unsigned int last_msec = 0;
static int bt_last = 0;

static void
gettimeofday_calibrate (void)
{
  const time_t t = time(NULL);
  const DWORD gtc = GetTickCount();
  gtc_base = t - gtc/1000;
  gtc_last = gtc;
}

/*
 * Rewritten by JY for OpenVPN 2.1, after I realized that
 * QueryPerformanceCounter takes nearly 2 orders of magnitude
 * more processor cycles than GetTickCount.
 */
int
openvpn_gettimeofday (struct timeval *tv, void *tz)
{
  const DWORD gtc = GetTickCount();
  int bt = 0;
  time_t sec;
  unsigned int msec;
  const int backtrack_hold_seconds = 10;

  /* recalibrate at the dreaded 49.7 day mark */
  if (!gtc_base || gtc < gtc_last)
gettimeofday_calibrate ();
  gtc_last = gtc;

  sec = gtc_base + gtc / 1000;
  msec = gtc % 1000;

  if (sec == last_sec)
{
  if (msec < last_msec)
	{
	  msec = last_msec;
	  bt = 1;
	}
}
  else if (sec < last_sec)
{
  /* We try to dampen out backtracks of less than backtrack_hold_seconds.
	 Larger backtracks will be passed through and dealt with by the
	 TIME_BACKTRACK_PROTECTION code (if enabled) */
  if (sec > last_sec - backtrack_hold_seconds)
	{
	  sec = last_sec;
	  msec = last_msec;
	}
  bt = 1;
}

  tv->tv_sec = last_sec = sec;
  tv->tv_usec = (last_msec = msec) * 1000;

  if (bt && !bt_last)
gettimeofday_calibrate ();
  bt_last = bt;

  return 0;
}

int main(void) {
	struct timeval tv;
	long i;
	long n=10;
	time_t mark;
	mark = time(NULL);
	for(i=0;i

Re: [Openvpn-devel] OpenVPN 2.3-alpha1 preview 1 installer now available

[Samuli Seppänen]

Hi Jonathan,

This does not really address the issue you're having, but could you try
if using Alon's new buildsystem helps:



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:



Samuli


>> A preview of OpenVPN 2.3-alpha1 installer for Windows is now available
>> here:
>>
>> 
> 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

Re: [Openvpn-devel] OpenVPN 2.3-alpha1 preview 1 installer now available

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/02/12 14:47, Jonathan K. Bullard wrote:
> 2012/2/21 Samuli Seppänen 
>> A preview of OpenVPN 2.3-alpha1 installer for Windows is now
>> available here:
>> 
>> 
>
>> 
> 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-

Re: [Openvpn-devel] OpenVPN 2.3-alpha1 preview 1 installer now available

[Jonathan K. Bullard]

2012/2/21 Samuli Seppänen 
> A preview of OpenVPN 2.3-alpha1 installer for Windows is now available
> here:
>
> 

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

Re: [Openvpn-devel] [build] Windows build test

[Alon Bar-Lev]

On Wed, Feb 22, 2012 at 12:36 PM, Heiko Hund  wrote:
> On Wednesday 22 February 2012 10:32:23 Alon Bar-Lev wrote:
>> On Wed, Feb 22, 2012 at 12:27 PM, Heiko Hund  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.

Re: [Openvpn-devel] [build] Windows build test

[Heiko Hund]

On Wednesday 22 February 2012 10:32:23 Alon Bar-Lev wrote:
> On Wed, Feb 22, 2012 at 12:27 PM, Heiko Hund  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

Re: [Openvpn-devel] [build] Windows build test

[Alon Bar-Lev]

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  wrote:
> On Wed, Feb 22, 2012 at 12:27 PM, Heiko Hund  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.

Re: [Openvpn-devel] [build] Windows build test

[Alon Bar-Lev]

On Wed, Feb 22, 2012 at 12:27 PM, Heiko Hund  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.

Re: [Openvpn-devel] [build] Windows build test

[Heiko Hund]

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

[Openvpn-devel] Cross-compiled Windows binaries (32/64bit) available for testing

[Samuli Seppänen]

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:




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"

Re: [Openvpn-devel] [build] Windows build test

[Alon Bar-Lev]

2012/2/22 Samuli Seppänen :
> 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.

Re: [Openvpn-devel] [build] Windows build test

[Gert Doering]

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 g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpIjIpGQYXGg.pgp
Description: PGP signature

Re: [Openvpn-devel] [build] Windows build test

[Samuli Seppänen]

>> .
>> Build is here[1]
>>
>> 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 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.

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.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

Re: [Openvpn-devel] [build] Windows build test

[Alon Bar-Lev]

2012/2/22 Gert Doering :
> Hi,
>
> 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... :)
>> I guess for building the TAP-driver.
>
> No, that one builds fine with the msys build environment and the
> windows ddk.
>
> 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.
Mingw w64 is a great project.
If it is the only reason, we should stop supporting visual studio, supporting
only autoconf build system, get rid of Microsoft specific noise.
If in future there will be no MSVC alternative the effort will be
smaller to migrate
once than maintaining the implementation until that point.

Alon.

Re: [Openvpn-devel] [build] Windows build test

[Gert Doering]

Hi,

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... :)
> I guess for building the TAP-driver. 

No, that one builds fine with the msys build environment and the
windows ddk.

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.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpT7k5K1cgQd.pgp
Description: PGP signature

Re: [Openvpn-devel] [build] Windows build test

[Samuli Seppänen]

Hi Alon,
> Hello people who actually use Windows!
>
> I will appreciate if you test my new windows build environment for OpenVPN.
I'll test this today.

> You have many options, I guess all are needed.
>
> While you at it, please try to explain me why we need Visual Studio build... 
> :)
I guess for building the TAP-driver. Besides that, I've never had a
clear idea :).

> .
> Build is here[1]
>
> BEST METHOD - Compile on Linux

Agreed :).
>
> 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
> SLOWER METHOD - Compile on cygwin
>
> Read README for required packages.
>
> $ cd generic
> $ IMAGEROOT=`pwd`/image-win32 CHOST=i686-w64-mingw32
> CBUILD=i686-pc-cygwin ./build
> $ IMAGEROOT=`pwd`/image-win64 CHOST=x86_64-w64-mingw32
> CBUILD=i686-pc-cygwin ./build
>
> Visual Studio Complete Batch
>
> install perl
>
>> cd msvc
>> build
> Visual Studio IDE
>
> After you have the dependencies of Complete Batch or your own.
> Create msvc-env-local.bat with OPENVPN_DEPROOT pointing to the
> location of the dependencies.
>
>> msvc-dev
> MSBuild
>
> After you have the dependencies of Complete Batch or your own.
> Create msvc-env-local.bat with OPENVPN_DEPROOT pointing to the
> location of the dependencies.
>
>> msvc-build
> Good luck,
> Alon.
>
> [1] https://github.com/alonbl/openvpn-build
>
> --
> 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 list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel


-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

Re: [Openvpn-devel] [PATCH 00/35] build revolution

[Alon Bar-Lev]

On Wed, Feb 22, 2012 at 9:16 AM, Frank de Brabander
 wrote:
> make & make check both run OK, but is it normal that make check
> doesn't do anything anymore?

Is make check worked for you?
OpenVPN tests need manual configuration and run as root.
Manual tests cannot be executed by build system as build system
must be automated.

Re: [Openvpn-devel] [PATCH 00/35] build revolution

[Frank de Brabander]

dhcp-091:openvpn_src brabander$ git clone --branch build
https://github.com/alonbl/openvpn.git openvpn_alonbl
Cloning into openvpn_alonbl...
remote: Counting objects: 7257, done.
remote: Compressing objects: 100% (1499/1499), done.
remote: Total 7257 (delta 5860), reused 7106 (delta 5709)
Receiving objects: 100% (7257/7257), 2.17 MiB | 621 KiB/s, done.
Resolving deltas: 100% (5860/5860), done.
dhcp-091:openvpn_src brabander$ cd openvpn_alonbl/
dhcp-091:openvpn_alonbl brabander$ autoreconf -i -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: running: glibtoolize --copy
glibtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'.
glibtoolize: copying file `./ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
glibtoolize: copying file `m4/libtool.m4'
glibtoolize: copying file `m4/ltoptions.m4'
glibtoolize: copying file `m4/ltsugar.m4'
glibtoolize: copying file `m4/ltversion.m4'
glibtoolize: copying file `m4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:39: installing `./config.sub'
configure.ac:38: installing `./missing'
configure.ac:38: installing `./install-sh'
configure.ac:39: installing `./config.guess'
src/openvpn/Makefile.am: installing `./depcomp'
autoreconf: Leaving directory `.'
dhcp-091:openvpn_alonbl brabander$ ./configure PKG_CONFIG=false
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking build system type... i386-apple-darwin11.3.0
checking host system type... i386-apple-darwin11.3.0
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for AIX... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking pkg-config is at least version 0.9.0... no
checking how to run the C preprocessor... gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for ifconfig... /sbin/ifconfig
checking for route... /sbin/route
checking for ip... no
checking for netstat... netstat
checking for man2html... no
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc...
/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
checking if the linker
(/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU
ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
checking the name lister (/usr/bin/nm) interface... BSD nm
checking the maximum length of command line arguments... 196608
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm output from gcc object... ok
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... y

[Openvpn-devel] [build] Windows build test

[Alon Bar-Lev]

Hello people who actually use Windows!

I will appreciate if you test my new windows build environment for OpenVPN.

You have many options, I guess all are needed.

While you at it, please try to explain me why we need Visual Studio build... :)
. 
Build is here[1]

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

SLOWER METHOD - Compile on cygwin

Read README for required packages.

$ cd generic
$ IMAGEROOT=`pwd`/image-win32 CHOST=i686-w64-mingw32
CBUILD=i686-pc-cygwin ./build
$ IMAGEROOT=`pwd`/image-win64 CHOST=x86_64-w64-mingw32
CBUILD=i686-pc-cygwin ./build

Visual Studio Complete Batch

install perl

> cd msvc
> build

Visual Studio IDE

After you have the dependencies of Complete Batch or your own.
Create msvc-env-local.bat with OPENVPN_DEPROOT pointing to the
location of the dependencies.

> msvc-dev

MSBuild

After you have the dependencies of Complete Batch or your own.
Create msvc-env-local.bat with OPENVPN_DEPROOT pointing to the
location of the dependencies.

> msvc-build

Good luck,
Alon.

[1] https://github.com/alonbl/openvpn-build