[solved] Cmake build error (and wolfssl error in alpine)

I got docker alpine images to compile OpenWrt 18.06 now, I had to add the file package as well.

1 Like

Ahh, awesome :slight_smile:

Now I like to figure out the cmake error that made me use docker images in the first place. :smiley:

For some reason (tm) the shebang line gets messed up in wolfssl generated configure script, that's why it errors out I'd guess.
#! /bin/sh

Edit: wolfssl

...but maybe that's ok?

I am not sure. this is a weird error. Removing the space from openwrt/build_dir/target-mips_24kc_musl/wolfssl-3.15.3-stable/m4/ax_create_generic_config.m4 did not help.

I've found the issue, it's /bin/sh which is busybox on Alpine and dash on Debian.
Changing the shebang to bash works just fine but not optimal.

To be clear, it's a regression but I'm not sure what the best fix would be.

Are you considering removing the shebang altogether and instead specifying a dependency on a single type of shell via cmake (if you really need a specific shell.)

Maybe if it's just a case of using a shell script, the script could be re-written using something else and removed?

@diizzy this is the cause: https://github.com/wolfSSL/wolfssl/commit/1b9cff1c5d09adb0af858992e2a2df01b1d4dc58

Reverting it fixes the error - but I do not known why this introduces the bug.

Oh, good job!

I wonder if it would be a bad idea to provide a version of dash in toolchain which always is used or to provide a mechanism for specifying shebang override per package?

@dizzy workarounds for bugs should be the last resort. I will report the error upstream. It is better to patch out these lines for the time being. the wolfssl package already removes broken build configuration stu.ff.

EDIT: reported bug: https://github.com/wolfSSL/wolfssl/issues/2132

Well, it worked using 3.8.2 (busybox 1.28.4) and stopped in 3.9.0 (busybox 1.29.3) so I'd say it's a regression in busybox most likely.
https://git.alpinelinux.org/aports/tree/main/busybox/APKBUILD?h=v3.8.2
https://git.alpinelinux.org/aports/tree/main/busybox/APKBUILD?h=v3.9.0

I can confirm that from alpine linux 3.8 to 3.9 the error with wolfssl appears. And removing the mentioned wolfssl commit fixes the problem.
I wonder what has changed in busybox...

Btw. the output of ar did not change in a way that would affect the pattern matching done in the wolfssl commit.

Hmmm. Regression? Or a change that exposes an usage of a quirk that has worked earlier...

Looking at relevant busybox ash changelogs leading to 1.29.3, there are several items to be more strict about bashism etc.
Practically all commits in 2018 are after 1.28.x
https://git.busybox.net/busybox/log/shell/ash.c?h=1_29_stable

The bug might be rather indirect. The problematic wolfssl change defines a variable to be used by libtool. My guess is that the handling of this AR_FLAGS variable in libtool contains some bashism that gets now mishandled/ignored by busybox when it is more strict about that. Or something similar.

Edit
Assuming that alpine had standard libtool (unlike OpenWrt), it is likely something related to the relevant lines in these commits
http://git.savannah.gnu.org/cgit/libtool.git/log/?qt=grep&q=Ar_flags

Ps. Especially this commit message seems relevant for wolfssl in general, as wolfssl is patching itself further away from the current libtool ar flag default "cr".

ARFLAGS: use 'cr' instead of 'cru' by default

In some GNU/Linux distributions people started to compile 'ar'
binary with --enable-deterministic-archives (binutils project).
That, however, in combination with our previous long time working
default AR_FLAGS=cru causes warnings on such installations:
ar: `u' modifier ignored since `D' is the default (see `U')

The 'u' option (at least with GNU binutils) did small optimization
during repeated builds because it instructed 'ar' to not
open/close unchanged *.o files and to rather read their contents
from old archive file.  However, its removal should not cause a
big performance hit for usual workflows.

Distributions started using --enable-deterministic-archives
knowing that it would disable the 'u', just to rather have a bit
more deterministic builds.

Also, to justify this change a bit more, keeping 'u' in ARFLAGS
could only result in many per-project changes to override
Libtool's ARFLAGS default, just to silent such warnings.

@hnyman
I would assume that it uses toolchain libtool in both cases?

So?
That was not my point.

My guess was that defining that variable changes the execution path in libtool (which is /bin/sh shell script) in a way where the new behaviour of busybox has impact.

That is just a guess, and I have not tried to evaluate it any closer. But as mwarning pointed out, the wolfssl commit itself looks quite innocent. So, the impact comes from the change that it makes further in the execution path.

If that's not the point why "Assuming that alpine had standard libtool (unlike OpenWrt), it is likely something related to the relevant lines in these commits" as it would be irrelevant?

You are right, that part of the message is an oversight from me.

I think I might have found the root cause: https://github.com/wolfSSL/wolfssl/pull/2137#issuecomment-469749964

1 Like

OpenWrt pull request: