Re: [GNUnet-developers] building on OpenWrt with musl

[Daniel Golle]

Hi!

On Tue, Jun 16, 2015 at 11:48:33PM +0200, Christian Grothoff wrote:
> >>> 010-cross-compile-fixes.patch
> >>> don't use AC_UNALIGNED_64_ACCESS, it's unavailable when cross-compiling
> >>
> >> Why do you comment it out? The macro is written to make the conservative
> >> choice when cross-compiling, at least as far as I can see it doesn't
> >> fail hard.  If it does fail hard when the macro is run, please let me
> >> know (ideally with details, such as config.log).
> > 
> > It does fail because align.m4 needs to run a test program which is not
> > an option when cross-compiling. I didn't see a way to replace it by
> > pre-compiler stuff or anything not requiring run-time evaluation, so
> > all I had left was skipping it.
> 
> Hmm.  AC_RUN_IFELSE uses 4 args, the program to compile & run, what to
> do on success, on failure, and on cross-compilation.
> align.m4 properly gives all 4 arguments, so it should really set
> ac_cv_unaligned_64_access=no on cross-compilation.  Again, could you
> please send me config.log (off-list is fine)?

...
checking for IceConnectionNumber in -lICE... no
checking for build target... linux
checking whether unaligned 64-bit access works... configure: error: in 
`/usr/src/openwrt/build_dir/target-mips_34kc_musl-1.1.9/gnunet-0.10.1-svn35937':
configure: error: cannot run test program while cross compiling
See `config.log' for more details

config.log doesn't include any further hints than that from what I can
see, I'll also send it to you off-list.


> I'm still confused as to what the issue is, and there seems to be some
> confusion as to the time at which there might be conflicts, namely at
> compile-time (when cross-compiling) and at run-time (when running on
> OpenWRT):

At compile time, and only technically only when building both curl and
gnurl. Below I'll try to explain things more deeply why this is a valid
and desired case, eg. when building a general purpose binary
distribution for specific target platform.

> * There shouldn't be a problem with the *installation* as clearly you
>   wouldn't want to install the HEADERS on the OpenWRT in the first
>   place. After all, you're cross-compiling, so you should only install
>   libgnurl.so, and for that there is no name conflict when you later
>   install libgnurl.so together with GNUnet, regardless of what curl-ish
>   stuff is on the system.  So just make sure you don't package the
>   headers and you're good.

True, but headers are staged inside the build-system which is
potentially used to build *all* packages, no matter if ever used
simultanously on the same system or not.
In OpenWrt, libraries install their headers into a shared staging area
used during build.
In order not to clash with curl's headers installed by
https://github.com/openwrt/packages/blob/master/net/gnurl/Makefile#L100
I chose to install gnurl's headers to /usr/include/gnurl, see
https://dev.openwrt.org/browser/trunk/package/network/utils/curl/Makefile#L159

> * If you're cross-compiling GNUnet, you don't need curl, you don't want
>   curl, so you don't have curl's curl.h. Instead, you are using gnurl
>   and thus get the curl.h from gnurl. Again, no conflict at that time,
>   just don't include curl in your GNUnet build environment if you
>   already have gnurl as a dependency.

This is only true if OpenWrt is used to directly build a specific
device firmware with specific packages installed, all *from source*.
However, being also a binary meta-distribution, OpenWrt can be used to
build *all* packages available for a specific target platform.
The packages can then later on be used to create firmware images for
devices using the ImageBuilder. e.g.

http://downloads.openwrt.org/snapshots/trunk/x86/64/OpenWrt-ImageBuilder-x86-64.Linux-x86_64.tar.bz2

Online binary repositories allowing users to install packages using
opkg after initially installing OpenWrt are also available, e.g.

http://downloads.openwrt.org/snapshots/trunk/x86/64/packages/packages/

The build process to create all packages includes curl (with OpenWrt's
default settings applied, ie. no SSL) which already stages its
headers at /usr/include/curl.
The resulting libcurl is not usable for GNUnet as it lacks any SSL
support. Changing the default settings of curl is currently not an
option -- having the curl package build all the t * 2^p different
variants, as we previously discussed, is an option, however, it's
quite a lot of work. Given that OpenWrt got their own client lib

http://git.openwrt.org/project/uclient.git

it's quite unlikely that anyone will put a lot of work into curl which
I'd consider a legacy piece of software we'd want to get rid of.
This why I initially chose to package gnurl following your arguments
that curl's code quality is quite heterogenous, ranging from being used
in harsh production environments down to hardly ever used by anyone.
All you wanted was HTTP and HTTPS, ie. the production-quality stuff.
Also there is no way for users of the curl library to decide which SSL
implementation to use, and that applies also to the curl package on
OpenWrt which *can* be configured to use GnuTLS. The GNUnet package
could depend on a specific rigid combination of the curl package's
menuconfig settings -- however, that would result in GNUnet simply not
being part of the binary distribution as its dependencies are not
fulfilled by curl's default settings.

So, as it was you creating gnurl for exactly these reasons, I guess
I can stop here.


> * If you don't want curl and gnurl on the system for space reasons,
>   and must have curl for other reasons, you can use cURL with GnuTLS
>   for GNUnet instead of gnurl -- assuming your other curl use is
>   happy with that. Otherwise, you get a wonderful mess of
>   OpenSSL, GnuTLS, curl and gnurl at the same time.

I agree. The world is a terrible mess. However, nobody can force-fix
it -- attempts to do so will create more problems.
I tried following the above approach and hit other problems. I wanted
curl with working SSL and used to build against embedtls. To satisfy
GNUnet's requirements, I switched to gnutls, resulting in both, gnutls
and embedtls being installed on the target system, as I also use other
things on OpenWrt which do not support gnutls but do support embedtls.
Apart from that, gnutls apparently expects a single combined CA blob
and handling /etc/ssl/certs/* seems broken, we also discussed that
earlier as it also breaks GNUnet bootstrapping if HELOs are loaded
via HTTPS.
I wanted curl to setup an IPv6 tunnel broker endpoint via HTTPS and
installed the ca-certificates packages populating /etc/ssl/certs --
that works well with embedtls and openssl, but doesn't when building
curl with gnutls.
Thus I packaged gnurl and put "port tunnel broker and dyndns stuff
to use uclient" on the todo list...

> * If you are making a "-dev" package with the headers so that one
>   could compile stuff on the OpenWRT device, then just put a
>   conflict between curl-dev and gnurl-dev.

I understand that this is what you can do on Debian and probably most
non-embedded distributions out there.
On OpenWrt, however, all packages share a single staging area for their
headers *during build time* and packages are not supposed to overwrite
any headers installed by other packages.
I could simply require the original curl package to stage its headers
using a build-dependency toward curl in the gnurl package and not
have gnurl stage any headers at all. Patching the path of the included
headers (and that could probably be done automagically with some
precompiler macros) and have gnurl install its headers to
/usr/include/gnurl seemed much more clean to me.


> Still problematic? Please try to explain better if so, I just don't
> understand the problem.

I hope I spread some light into the issue.


Cheers


Daniel