fail to build on any macos/linux

[Clodo76]

Issue occur in:

• macOS BigSur M1
• macOS Catalina
• linux (any x86, tested on Debian7)
• linux (any x64, tested on Debian7)
• any raspberry (armv7i or aarch64).

How to reproduce:

git clone https://github.com/OpenVPN/openvpn-build.git
cd openvpn-build 
cd generic 
IMAGEROOT=`pwd`/image-native ./build

Build log:

make[1]: windres: Command not found
Makefile:104: recipe for target 'liblz4-dll.o' failed
make[1]: [liblz4-dll.o] Error 127 (ignored)
ar rcs liblz4.a *.o
make[1]: Leaving directory 'openvpn-build/generic/tmp/lz4-1.9.3/lib'
make[1]: Entering directory 'openvpn-build/generic/tmp/lz4-1.9.3/programs'
gcc -O3   -I../lib -DXXH_NAMESPACE=LZ4_  -c -o bench.o bench.c
gcc -O3   -I../lib -DXXH_NAMESPACE=LZ4_  -c -o datagen.o datagen.c
gcc -O3   -I../lib -DXXH_NAMESPACE=LZ4_  -c -o lz4cli.o lz4cli.c
gcc -O3   -I../lib -DXXH_NAMESPACE=LZ4_  -c -o lz4io.o lz4io.c
creating executable resource
sed -e 's|@PROGNAME@|lz4|' \
         -e 's|@LIBVER_MAJOR@|1|g' \
         -e 's|@LIBVER_MINOR@|9|g' \
         -e 's|@LIBVER_PATCH@|3|g' \
         -e 's|@EXT@|.exe|g' \
          lz4-exe.rc.in >lz4-exe.rc
windres -i lz4-exe.rc -o lz4-exe.o
make[1]: windres: Command not found
Makefile:80: recipe for target 'lz4-exe.o' failed
make[1]: [lz4-exe.o] Error 127 (ignored)
gcc -O3   -I../lib -DXXH_NAMESPACE=LZ4_   ../lib/lz4.o ../lib/lz4frame.o ../lib/lz4hc.o ../lib/xxhash.o bench.o datagen.o lz4cli.o lz4io.o lz4-exe.o -o lz4.exe
gcc: error: lz4-exe.o: No such file or directory
Makefile:83: recipe for target 'lz4' failed
make[1]: [lz4] Error 1 (ignored)
make[1]: Leaving directory 'openvpn-build/generic/tmp/lz4-1.9.3/programs'
cp: cannot stat ‘programs/lz4.exe’: No such file or directory
Makefile:59: recipe for target 'lz4-release' failed
make: *** [lz4-release] Error 1
FATAL: make lz4

the 1 april, this commit was accepted: https://github.com/OpenVPN/openvpn-build/commit/6a3aade3b298b505fdd9fafc5f6f3c2ab8339c64#diff-43f4d3b433a283401aeb21409df4d3b088b2c848cc0ca9fe55a2fc68edb294b4

it's normal that contain hardcoded "TARGET_OS=MINGW32" in 'build' script?

@cron2

[cron2]

Hi,

On Fri, Jul 16, 2021 at 04:34:01AM -0700, Clodo76 wrote:

the 1 april, this commit was accepted: https://github.com/OpenVPN/openvpn-build/commit/6a3aade3b298b505fdd9fafc5f6f3c2ab8339c64#diff-43f4d3b433a283401aeb21409df4d3b088b2c848cc0ca9fe55a2fc68edb294b4

it's normal that contain hardcoded "TARGET_OS=MINGW32" in 'build' script?

Maybe not. But nobody we know uses openvpn-build for anything that is not MinGW-crossbuilding, so that seems to be an oversight. Patches welcome.

For "I just want to build openvpn on a unix platform", just downloading the tarballs / cloning the git repo is very straightforward.

gert

-- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany @.***

[Clodo76]

"Nobody" ... me ... So, i need to start building my build script and deprecate this for all arch i use, OR understand how to patch this. I suggest to rename this project "openvpn-build-mingw" to avoid confusion. Thanks anyway for your reply.

[cron2]

Hi,

On Sat, Jul 17, 2021 at 04:02:03AM -0700, Clodo76 wrote:

"Nobody" ... me ... So, i need to start building my build script and deprecate this for all arch i use, OR understand how to patch this. I suggest to rename this project "openvpn-build-mingw" to avoid confusion. Thanks anyway for your reply.

Sorry for breaking your use case. Repairing mingw was most important on my mind (= adding lz4 building), because that's crucial for most platforms.

Most likely you can just add a big #if around this (or just comment it out) if your platforms ship a lz4 library - that would then be "like it was before the patch".

gert

"If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany @.***

[sdbbs]

Hi,

I just wanted to say thanks for this post.

This is my use case: I have a cheapish web hotel, and I just discovered it has a (browser) terminal in its control panel. It is likely a custom linux system, as there is no apt nor pacman or any package manager that I know - the only thing I can tell is, it runs Linux 3 kernel (via uname).

So, I cannot really install dependencies - but, it turns out it has a gcc, make, etc (I guess, the whole build-essential). So I took it up as a challenge to build openvpn on this system, even if I probably won't be able to run it (since there is no sudo nor su here).

That is why I was very happy to see https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#BuildingOpenVPNanditsdependencies

The ./build command fetches all the dependencies, builds them and builds OpenVPN. To build a native binary:

$ IMAGEROOT=`pwd`/image-native ./build

So, I did just that - and the process actually ran, until it broke at windres: Command not found, as in the OP.

So, thanks to this post, I'm happy to report that just removing the

WINDRES=${CHOST}-windres TARGET_OS=MINGW32 \

.... lines from the ./build file (can't really comment them, due to escaping of newline), helps that openvpn finally builds also on this platform - the executable ending up in openvpn-build/generic/image-native/openvpn/sbin/openvpn (and it runs also, as it dumps the help text when called without any arguments).

[flichtenheld]

We have decided to remove the nsis/mingw buildsystem since it is not maintained anymore. Only the msi/msvc buildsystem will remain, unless someone steps up to maintain the other parts. This issue will be closed when the removal actually happens.

[flichtenheld]

Moving the MinGW builds of OpenVPN to use CMake+VCPKG. Support is already in master and will be backported to release/2.6. There is definitely no plan to address this in the context of "generic". So closing this issue.