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

[Daniel Golle]

Hi Christian,

On Tue, Jun 16, 2015 at 03:29: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.


> > 011-no-fpu-includes.patch
> > don't #include <fenv.h>, it's specific to systems with FPU and doesn't
> > seem to be used anyway (?)
> 
> Indeed, seems to be a left-over, removed in SVN 35934.

Great, thanks.

> > 012-work-around-bad-workarounds.patch
> > gnurl on OpenWrt installs it's headers to /usr/include/gnurl rather
> > than /usr/include/curl to avoid colliding with existing vanilla-cURL
> > headers -- fix the location of the included headers in GNUnet to use
> > /usr/include/gnurl as well.
> 
> Ugh, the issue is that 'gnurl' is really just curl with certain
> configure options, and on some platforms GNUnet is still linked against
> curl, which this patch would break. Not to mention that gnurl (still)
> installs its headers to the curl/-location (as they are identical
> anyway, and gnurl is supposed to work as a drop-in replacement).  Given
> that on OpenWRT you probably don't want curl with SMTP/SSH/etc. support,
> have you considered changing the default curl-installation on OpenWRT to
> be GNUnet-compatible (this mostly means that it must be linked against
> the GnuTLS backend)?  Having both curl and gnurl on an embedded system
> doesn't make sense anyway, and so I do believe it makes sense for the
> development headers to conflict: pick one to use, and then use that for
> the entire system. Pick wisely ;-).

Well, people are free to configure curl in any way they want to on
OpenWrt when compiling from source, see:
https://dev.openwrt.org/browser/trunk/package/network/utils/curl/Config.in

The problem here, however, arises already during compile time
independently of the curl/gnurl packages ever being installed on the
same system simultanously.

In short:
 * there should not be a build-dependency towards curl for having the
   headers in place, thus gnurl has to installed it's headers
 * gnurl cannot install headers to /usr/include/curl, as those files
   would then collide with files installed by real-cURL....
 * GNUnet cannot depend on real-cURL being configured in a certain way
 * People may actually want cURL with OpenSSL installed on the same
   system they also use for GNUnet because gnurl/gnutls's handling of
   CA certs in /etc/ssl/certs doesn't work and is needed e.g. for some
   dyndns services...
 * I thought the whole point of gnurl was to NOT have any compile-time
   choices and always get the same features. The oposite applies to
   cURL where you do have all those compile-time/linking choices.


> > 100-musl-malloc.patch
> > musl doesn't provide mallopt, thus check for __GLIBC__ before making
> > use of GLIBC-specific malloc features.
> 
> Fixed as suggested in SVN 35935.

Thanks!


> > 101-include-byteswap.patch
> > byteswap.h may have been implicitely included on GLIBC systems.
> > When building with musl it needs to be explicitely included.
> 
> Changed in 35936, but also added a configure check for byteswap.h, as I
> don't know about this header on other platforms (i.e. FreeBSD, W32, OS
> X, etc.).

Cool, I wasn't sure about how to do the automagic for that one.


Cheers


Daniel