openvpn-devel Mailing List for OpenVPN

On Sun, Feb 26, 2012 at 7:49 PM, mark <mnu...@ha...> wrote: >  From e15b874fdd05e9952e94e36292b57071e96127ed Mon Sep 17 00:00:00 2001 > From: Mark Nunberg <mnu...@ha...> > Date: Sun, 26 Feb 2012 09:37:33 -0800 > Subject: [PATCH] Allow management socket over inherited file descriptor > > Allows a direct management channel over a forked-and-execed openvpn > process (or possibly other means) instead of having to use a bound TCP > or UNIX socket. Helpful for wrapper applications and advanced scripts, > so that they leave less clutter in the local connection table and/or > filesystem > --- Most implementations separate between the privileges required to ran the daemon and he privileges requires to run the management logic. Why is this actually needed? And why do you think the unix sockets are insufficient? Alon. 

 From e15b874fdd05e9952e94e36292b57071e96127ed Mon Sep 17 00:00:00 2001 From: Mark Nunberg <mnu...@ha...> Date: Sun, 26 Feb 2012 09:37:33 -0800 Subject: [PATCH] Allow management socket over inherited file descriptor Allows a direct management channel over a forked-and-execed openvpn process (or possibly other means) instead of having to use a bound TCP or UNIX socket. Helpful for wrapper applications and advanced scripts, so that they leave less clutter in the local connection table and/or filesystem --- manage.c | 22 ++++++++++++++++++++-- manage.h | 1 + options.c | 9 ++++++++- 3 files changed, 29 insertions(+), 3 deletions(-) diff --git a/manage.c b/manage.c index ce6fae7..f597ed9 100644 --- a/manage.c +++ b/manage.c @@ -1587,7 +1587,7 @@ man_listen (struct management *man) } else #endif - { + { man->connection.sd_top = create_socket_tcp (); socket_bind (man->connection.sd_top, &man->settings.local, "MANAGEMENT"); } @@ -1612,9 +1612,11 @@ man_listen (struct management *man) } else #endif + { msg (D_MANAGEMENT, "MANAGEMENT: TCP Socket listening on %s", print_sockaddr (&man->settings.local, &gc)); } + } #ifdef WIN32 man_start_ne32 (man); @@ -1623,6 +1625,16 @@ man_listen (struct management *man) gc_free (&gc); } +static void man_connect_from_sockfd(struct management *man) +{ + /*We have a socket already opened for us. Simple enough*/ + man->connection.sd_top = SOCKET_UNDEFINED; + man->connection.state = MS_INITIAL; + man->connection.sd_cli = man->settings.local.addr.in4.sin_port; + man_record_peer_info(man); + man_new_connection_post(man, "Connected from sockfd"); +} + static void man_connect (struct management *man) { @@ -2029,6 +2041,10 @@ man_settings_init (struct man_settings *ms, sockaddr_unix_init (&ms->local_unix, addr); else #endif + if(ms->flags & MF_SOCKFD) { + ms->local.addr.in4.sin_port = atoi(addr); + } + else { /* * Initialize socket address @@ -2111,7 +2127,9 @@ man_connection_init (struct management *man) /* * Listen/connect socket */ - if (man->settings.flags & MF_CONNECT_AS_CLIENT) + if(man->settings.flags & MF_SOCKFD) + man_connect_from_sockfd(man); + else if (man->settings.flags & MF_CONNECT_AS_CLIENT) man_connect (man); else man_listen (man); diff --git a/manage.h b/manage.h index f681f8d..ab939ff 100644 --- a/manage.h +++ b/manage.h @@ -339,6 +339,7 @@ struct management *management_init (void); #if MANAGEMENT_QUERY_REMOTE #define MF_QUERY_REMOTE (1<<11) #endif +#define MF_SOCKFD (1<<12) bool management_open (struct management *man, const char *addr, diff --git a/options.c b/options.c index 736495e..07a2972 100644 --- a/options.c +++ b/options.c @@ -371,6 +371,10 @@ static const char usage_message[] = " To listen on a unix domain socket, specific the pathname\n" " in place of ip and use 'unix' as the port number.\n" #endif + " To specify a numeric file descriptor of a connected\n" + " socket (in the case of openvpn running as a forked process)\n" + " specify the file descriptor number as the pathname, and \n" + " 'sockfd' as the port number\n" "--management-client : Management interface will connect as a TCP client to\n" " ip/port rather than listen as a TCP server.\n" "--management-query-passwords : Query management channel for private key\n" @@ -4076,7 +4080,10 @@ add_option (struct options *options, msg (msglevel, "MANAGEMENT: this platform does not support unix domain sockets"); goto err; #endif - } + } else if(streq(p[2], "sockfd")) { + options->management_flags |= MF_SOCKFD; + /*Check to see if socket address is too big..*/ + } else { port = atoi (p[2]); -- 1.7.2.5 

This is my last reply on this thread. What I show you is that without any change I compile static code for arm using cross compiler. I guess I am far more knowledgeable than you to tell me what is right, and I disapprove your comments and language. So the answer to your initial question: yes, openvpn can be compiled statically. Figure it out your-self. On Sun, Feb 26, 2012 at 5:42 PM, Mr Dash Four <mr....@go...> wrote: > >> arm-unknown-linux-gnueabi-objdump: >> image-arm-static/openvpn/sbin/openvpn: Invalid operation >> > > Huh? > > Have you altered the sources/makefiles of openvpn or any of the dependent > libraries (lzo, openssh etc) by any chance? I noticed you are applying a > single patch to the lzo source, which I had to re-adjust as I was using a > newer version, but I am not aware of any alterations that you have made to > these - if you have done so, please state what these alterations are? > > I don't know whether you've altered the original build script or not, but > the end result, before applying my changes, clearly produces openvpn > executable, which has external dependencies on all statically-produced .la > files/libraries (lzo, openssh etc) - they are all packed in the .tar archive > produced at the end of this script (located in the /lib directory to be more > precise). > > I don't know what you are trying to prove by posting the above though - the > final gcc linker call, which produces the openvpn executable before packing > the image does *not* have any static-linking related options whatsoever! I > could post the exact gcc command line, but I do not have access to that > machine at present. > > These options are, as I already pointed out previously, "-static", > "-static-gcc" as well as "-ldl" - the latter being a new dependencies, > necessary to offset the fact that all dl* calls (dlopen etc) won't be > satisfied if static linking is invoked, so this external library needs to be > included so that static linking succeeds, otherwise you will get "unknown > symbol" errors. > > Again, all that is provided you haven't altered any of the core source > and/or makefile scripts in any way (I haven't used your own - alonbv - repos > to download these, but downloaded these packages from their original source > where these projects are created - openvpn.net, openssh.org etc). If you > have made such alterations, I'd like to know what changes have you made? > 

That does it - it works now, thanks!!! ... Russell On Sat, 02/25/2012 12:58 PM, Alon Bar-Lev <alo...@gm...> wrote: > Never mind. > I guess that mingw is configured as multilib somehow. > I forced all to use /lib. > Can you please try again? > > On Sat, Feb 25, 2012 at 7:28 PM, Alon Bar-Lev <alo...@gm...> wrote: > > Can you send me list: > > $ find image-win32/openvpn/lib > > $ find image-win32/openvpn/lib64 > > > > > > On Sat, Feb 25, 2012 at 4:22 PM, Russell Morris <op...@rk...> wrote: > >> Hi, > >> > >> OK, I have done some digging - and I know what the issue is! Not sure how to > >> fix it though ... :-). > >> > >> Inside the image-win64 directory, and then inside openvpn - running the > >> build script results in two directories, lib and lib64 (for image-win32 > >> there is only the lib directory). The libraries noted as missing are inside > >> lib64, not lib ... so they are not seen. I have seen this issue before. Then > >> the fix was to link lib64 to lib, and I tried this in this case - but the > >> script seems to delete the directories and recreate them (so the link is > >> gone). > >> > >> Thoughts? > >> > >> Thanks! > >> > >> ... Russell > >> > >> > >> > >> > >> On Sat, 02/25/2012 03:23 AM, Alon Bar-Lev <alo...@gm...> wrote: > >> > >> And also full output of the build script... > >> > >> ..... 2>&1 | gzip > /tmp/build.log > >> > >> On Sat, Feb 25, 2012 at 11:14 AM, Alon Bar-Lev <alo...@gm...> > >> wrote: > >>> I need the tmp/openvpn*/config.log > >>> > >>> On Sat, Feb 25, 2012 at 7:12 AM, Russell Morris <op...@rk...> > >>> wrote: > >>>> Hi, > >>>> > >>>> I used the command line you provided below (actually, copied and pasted > >>>> it > >>>> to the command line). The one having issues is: > >>>> IMAGEROOT=`pwd`/image-win64 > >>>> CHOST=x86_64-w64-mingw32 CBUILD=x86_64-pc-linux-gnu ./build > >>>> > >>>> Thanks! > >>>> > >>>> ... Russell > >>>> > >>>> > >>>> > >>>> On Fri, 02/24/2012 06:11 PM, Alon Bar-Lev <alo...@gm...> wrote: > >>>> > >>>> How exactly did you try to build? > >>>> Please send command-line. > >>>> > >>>> The mingw32 suffix is historic, it is kept for compatibility as old > >>>> autotools(config.guess) packages expects for mingw32 as a platform, in > >>>> the old days there was no (forced) standard for specifying the arch. > >>>> > >>>> On Sat, Feb 25, 2012 at 2:04 AM, Russell Morris > >>>> <ope...@rk...> wrote: > >>>>> Hi, > >>>>> > >>>>> First of all - thanks for this! It's very much appreciated! > >>>>> > >>>>> I tried this on my Linux box, and it worked fine - for the win32 image. > >>>>> However, the win64 image fails, with the following error ... > >>>>> > >>>>> ============================================================ > >>>>> > >>>>> > >>>>> > >>>>> /usr/lib64/gcc/x86_64-w64-mingw32/4.6.2/../../../../x86_64-w64-mingw32/bin/ld: > >>>>> cannot find -llzo2 > >>>>> > >>>>> > >>>>> /usr/lib64/gcc/x86_64-w64-mingw32/4.6.2/../../../../x86_64-w64-mingw32/bin/ld: > >>>>> cannot find -lpkcs11-helper > >>>>> collect2: ld returned 1 exit status > >>>>> make[3]: *** [openvpn.exe] Error 1 > >>>>> make[3]: Leaving directory > >>>>> > >>>>> > >>>>> `/home/rmorris/Documents/Programming/openvpn-build/generic/tmp/openvpn-2.3-alpha1/src/openvpn' > >>>>> make[2]: *** [install-recursive] Error 1 > >>>>> make[2]: Leaving directory > >>>>> > >>>>> > >>>>> `/home/rmorris/Documents/Programming/openvpn-build/generic/tmp/openvpn-2.3-alpha1/src' > >>>>> make[1]: *** [install-recursive] Error 1 > >>>>> make[1]: Leaving directory > >>>>> > >>>>> > >>>>> `/home/rmorris/Documents/Programming/openvpn-build/generic/tmp/openvpn-2.3-alpha1' > >>>>> make: *** [install-strip] Error 2 > >>>>> FATAL: make openvpn > >>>>> > >>>>> ============================================================ > >>>>> > >>>>> Has anyone else seen this? Any thoughts how to correct it? > >>>>> > >>>>> Also, if you don't mind me asking - can anyone explain the naming > >>>>> convention > >>>>> for i686-w64-mingw32 vs. x86_64-w64-mingw32? They both seem to be > >>>>> "mingw32", > >>>>> so a bit confused how one is really 64 bit. > >>>>> > >>>>> Thanks again, > >>>>> ... Russell > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Tue, 02/21/2012 06:12 PM, Alon Bar-Lev <alo...@gm...> wrote: > >>>>> > >>>>> 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 > >>>>> > >>>>> > >>>>> > >>>>> ------------------------------------------------------------------------------ > >>>>> 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 > >>>>> Ope...@li... > >>>>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel > >>>> > >>>> > >>>> ------------------------------------------------------------------------------ > >>>> 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 > >>>> Ope...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel > 

 > arm-unknown-linux-gnueabi-objdump: > image-arm-static/openvpn/sbin/openvpn: Invalid operation > Huh? Have you altered the sources/makefiles of openvpn or any of the dependent libraries (lzo, openssh etc) by any chance? I noticed you are applying a single patch to the lzo source, which I had to re-adjust as I was using a newer version, but I am not aware of any alterations that you have made to these - if you have done so, please state what these alterations are? I don't know whether you've altered the original build script or not, but the end result, before applying my changes, clearly produces openvpn executable, which has external dependencies on all statically-produced .la files/libraries (lzo, openssh etc) - they are all packed in the .tar archive produced at the end of this script (located in the /lib directory to be more precise). I don't know what you are trying to prove by posting the above though - the final gcc linker call, which produces the openvpn executable before packing the image does *not* have any static-linking related options whatsoever! I could post the exact gcc command line, but I do not have access to that machine at present. These options are, as I already pointed out previously, "-static", "-static-gcc" as well as "-ldl" - the latter being a new dependencies, necessary to offset the fact that all dl* calls (dlopen etc) won't be satisfied if static linking is invoked, so this external library needs to be included so that static linking succeeds, otherwise you will get "unknown symbol" errors. Again, all that is provided you haven't altered any of the core source and/or makefile scripts in any way (I haven't used your own - alonbv - repos to download these, but downloaded these packages from their original source where these projects are created - openvpn.net, openssh.org etc). If you have made such alterations, I'd like to know what changes have you made? 

$ git clone https://github.com/alonbl/openvpn-build.git $ cd openvpn.build $ DO_REALLY_STATIC=1 IMAGEROOT=`pwd`/image-arm-static CHOST=arm-unknown-linux-gnueabi CBUILD=x86_64-pc-linux-gnu ./build $ file image-arm-static/openvpn/sbin/openvpn image-arm-static/openvpn/sbin/openvpn: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.16, stripped $ ls -hla image-arm-static/openvpn/sbin/openvpn -rwxr-xr-x 1 alonbl alonbl 2.3M Feb 26 17:09 image-arm-static/openvpn/sbin/openvpn $ arm-unknown-linux-gnueabi-objdump --dynamic-reloc image-arm-static/openvpn/sbin/openvpn image-arm-static/openvpn/sbin/openvpn: file format elf32-littlearm arm-unknown-linux-gnueabi-objdump: image-arm-static/openvpn/sbin/openvpn: not a dynamic object arm-unknown-linux-gnueabi-objdump: image-arm-static/openvpn/sbin/openvpn: Invalid operation On Sun, Feb 26, 2012 at 5:00 PM, Mr Dash Four <mr....@go...> wrote: > >> You can check if executable is static by using >> arm-unknown-linux-gnueabi-readelf --relocas. >> The fact that the archive has a lot of files does not mean the openvpn >> is not static. >> > > Well, I don't really know what you understand "static linking" to be, but to > me it means that all external functions, subroutines etc, which are resolved > at compile-time, are copied into a target application by the gcc linker, > producing an object file and then a stand-alone executable ("stand-alone" > being the key word here!). Your build script, evidently, does not do that > and I already pointed out the changes you may need to make to allow a > *stand-alone* openvpn executable to be produced. > > If you believe "static linking" to mean something else from what I described > above, please enlighten us all! > > If I have to deploy additional files alongside openvpn, then I may as well > have it dynamically linked and deploy the entire dependencies chain (using > ldd as guidance). The reason I can't/won't do that is because to satisfy > this, I have to 1) spend a lot of my time digging out dependencies, without > the guarantee that it would ever work, and 2) as my rootfs is read-only, > whatever I do it will be instantly lost on reboot, so the whole exercise > would be utterly pointless. > > >> Anyway it is working at my side, and it is a standard process. >> You can adjust the script for your needs. >> > > I already did, you may as well do the same and make the changes I suggested > earlier for the "really_static" option to really work, because, as it > stands, "really_static" isn't so as openvpn still needs external files to > operate. 

 > You can check if executable is static by using > arm-unknown-linux-gnueabi-readelf --relocas. > The fact that the archive has a lot of files does not mean the openvpn > is not static. > Well, I don't really know what you understand "static linking" to be, but to me it means that all external functions, subroutines etc, which are resolved at compile-time, are copied into a target application by the gcc linker, producing an object file and then a stand-alone executable ("stand-alone" being the key word here!). Your build script, evidently, does not do that and I already pointed out the changes you may need to make to allow a *stand-alone* openvpn executable to be produced. If you believe "static linking" to mean something else from what I described above, please enlighten us all! If I have to deploy additional files alongside openvpn, then I may as well have it dynamically linked and deploy the entire dependencies chain (using ldd as guidance). The reason I can't/won't do that is because to satisfy this, I have to 1) spend a lot of my time digging out dependencies, without the guarantee that it would ever work, and 2) as my rootfs is read-only, whatever I do it will be instantly lost on reboot, so the whole exercise would be utterly pointless. > Anyway it is working at my side, and it is a standard process. > You can adjust the script for your needs. > I already did, you may as well do the same and make the changes I suggested earlier for the "really_static" option to really work, because, as it stands, "really_static" isn't so as openvpn still needs external files to operate. 

Hello, You can check if executable is static by using arm-unknown-linux-gnueabi-readelf --relocas. The fact that the archive has a lot of files does not mean the openvpn is not static. Anyway it is working at my side, and it is a standard process. You can adjust the script for your needs. Alon. On Sun, Feb 26, 2012 at 3:21 PM, Mr Dash Four <mr....@go...> wrote: > >>> Reason being, I suspect, that the lzo static libraries cannot be found >>> (strange as the compilation succeeded). >>> >> >> >> I need tmp/openvpn/config.log >> Better to have the complete build output... >> > > This was done in mock environment (both the rpm and "normal" build). When I > did this from outside, using a specific arm cross-toolchain, the build > succeeded, *but* the package created does not contain static openvpn - it > still needs all of its dependencies (though them being statically-build > components, like lzo etc). The output produced from your build script seems > to be an archive, presumably containing all the files openvpn needs, spread > across multiple directories (I am also not sure whether openvpn produced in > this way won't need its libgc library). > > I suspect all I need to do is to unpack this archive to the target, but that > won't do me any good at all, because my root system on the android device is > squashfs (read-only) and whatever I do with it (provided I succeed) will be > destroyed the next time I reboot the device. What I need is a single openvpn > executable, so that I could just place it somewhere in my path and fire it > off. > > I was able to slightly amend the running order of openvpn compilation > process and succeeded in building a single, statically-linked openvpn > executable for my android device. > > The error your build script has with this is that the last statement which > links all objects into the openvpn executable should contain "-static", > "-static-libgcc" along with "-ldl" - currently you don't have that and the > openvpn executable produced is about 700kB, still needing its static > libraries at the very least. > > When openvpn is statically linked in the way I just described, the file > produced is about 7MB, coming down to about 1.7MB after stripping. Copying > this single file to my android device (and briefly testing it) seems to have > done the trick. > > One drawback from this, which is valid for *all* statically-linked > executables in this way, is that there are some arch-dependent functions, > like "gethostbyname", which are implemented, possibly in a different way in > different environments, hence when I statically link and produce one single > monolithic executable in such a way I get a warning from the linker, but > since I am not likely to use such functions, I think there is nothing to > worry about. 

 >> Reason being, I suspect, that the lzo static libraries cannot be found (strange as the compilation succeeded). >> > > I need tmp/openvpn/config.log > Better to have the complete build output... > This was done in mock environment (both the rpm and "normal" build). When I did this from outside, using a specific arm cross-toolchain, the build succeeded, *but* the package created does not contain static openvpn - it still needs all of its dependencies (though them being statically-build components, like lzo etc). The output produced from your build script seems to be an archive, presumably containing all the files openvpn needs, spread across multiple directories (I am also not sure whether openvpn produced in this way won't need its libgc library). I suspect all I need to do is to unpack this archive to the target, but that won't do me any good at all, because my root system on the android device is squashfs (read-only) and whatever I do with it (provided I succeed) will be destroyed the next time I reboot the device. What I need is a single openvpn executable, so that I could just place it somewhere in my path and fire it off. I was able to slightly amend the running order of openvpn compilation process and succeeded in building a single, statically-linked openvpn executable for my android device. The error your build script has with this is that the last statement which links all objects into the openvpn executable should contain "-static", "-static-libgcc" along with "-ldl" - currently you don't have that and the openvpn executable produced is about 700kB, still needing its static libraries at the very least. When openvpn is statically linked in the way I just described, the file produced is about 7MB, coming down to about 1.7MB after stripping. Copying this single file to my android device (and briefly testing it) seems to have done the trick. One drawback from this, which is valid for *all* statically-linked executables in this way, is that there are some arch-dependent functions, like "gethostbyname", which are implemented, possibly in a different way in different environments, hence when I statically link and produce one single monolithic executable in such a way I get a warning from the linker, but since I am not likely to use such functions, I think there is nothing to worry about. 

Hello, A repository is available[1], stripped down with only tap sources. To build use you need ddk available: > configure > build It builds winxp 32bit and win7 64bit I hope this is what the current installer is doing, as building the tap is kept secret. In the open source package we will provide vanilla devcon and not the modified tapinstaller which we do not have the sources of. I it is so important to hack computer and bypass Windows confirmation dialog. Left is to package it up. Alon. [1] https://github.com/alonbl/tap-windows/ 

On Sun, Feb 26, 2012 at 2:12 AM, Mr Dash Four <mr....@go...> wrote: >> To cross compile master to arm in static, do: >> $ git clone git://github.com/alonbl/openvpn-build.git >> $ cd openvpn-build/generic >> $ CHOST="arm-unknown-linux-gnueabi" CBUILD="x86_64-pc-linux-gnu" >> DO_STATIC=1 ./build >> >> It will create static dependencies, but dynamic libc, if you want >> really static use DO_REALLY_STATIC=1. > This build fails at the same point as in my srpm static compilation: > > checking for lzo1x_1_15_compress in -llzo2... no > checking for lzo1x_1_15_compress in -llzo... no > configure: error: LZO headers were found but LZO library was not found > FATAL: Configure openvpn > > > Reason being, I suspect, that the lzo static libraries cannot be found (strange as the compilation succeeded). I need tmp/openvpn/config.log Better to have the complete build output... Alon. 

> To cross compile master to arm in static, do: > $ git clone git://github.com/alonbl/openvpn-build.git > $ cd openvpn-build/generic > $ CHOST="arm-unknown-linux-gnueabi" CBUILD="x86_64-pc-linux-gnu" > DO_STATIC=1 ./build > > It will create static dependencies, but dynamic libc, if you want > really static use DO_REALLY_STATIC=1. This build fails at the same point as in my srpm static compilation: checking for lzo1x_1_15_compress in -llzo2... no checking for lzo1x_1_15_compress in -llzo... no configure: error: LZO headers were found but LZO library was not found FATAL: Configure openvpn Reason being, I suspect, that the lzo static libraries cannot be found (strange as the compilation succeeded).