gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christian Grothoff
Subject: Re: [GNUnet-developers] building on OpenWrt with musl
Date: Wed, 17 Jun 2015 11:13:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0

On 06/17/2015 01:47 AM, Daniel Golle wrote:
> 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.

Well, try SVN 35938. There was a typo in align.m4 with a bracket being
in the wrong place, which was actually easily spotted in the config.log.
So thanks for reporting ;-).

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

Ok, so you're not building packages, but full-platform, and for the full
platform, you're in the unfortunate position to possibly require
both curl and gnurl.

<some explanations cut>

> The resulting libcurl is not usable for GNUnet as it lacks any SSL
> support.

Just a little remark: you can use that libcurl for GNUnet, you'll just
not get certain GNUnet features (like running GNUnet over https, and
bootstrapping from hostlist on an HTTPS-server being the big one).
Still, I agree with your sentiment of "not usable" as I'd not recommend
such a setup (unless required for space).

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

Yep. ;-)

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

embedtls = mbedtls = PolarSSL?
Or is 'embedtls' yet another new TLS library? (Just curious.)

> 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 HELLOs are loaded
> via HTTPS.

Yep.

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

I feel your pain.

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

Well, or more hackish, detect the presence of the original curl package
and only if present, not install headers, otherwise do install them. As
Gnurl is committed to keeping the headers identical (modulo version
differences...), that will just work.  Not 100% clean, but your fix
isn't working quite right either: with the headers in include/gnurl/,
the 'gnurl.m4' macro will fail to find them (and thus 'make' will not
even attempt to compile the gnurl-dependent logic) unless curl is also
present (and then you use a check for 'include/curl' to compile against
'include/gnurl'...).  Sure, we could fix the gnurl.m4 to also check in
include/gnurl, but gnurl.m4 is again a straight copy from curl.m4, so
we'd break 1:1 drop-in with that. Not to mention the "simple" idea of
switching between curl and gnurl by -l flag goes away once you do have
to change the C source #include's and the build system to support the
necessary conditional compilation, etc.

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

Yes, thanks a lot!  I think I understand now where the issue comes from,
but I don't have a "clean" solution. Simply having the gnurl package not
install its headers if the curl headers are already present seems the
cleanest approach to me, but it's still a hack. But, by pointing to this
discussion on the list, it'll at least be a very well documented hack ;-).

Happy hacking!

Christian

Attachment: 0xE29FC3CC.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]