On 06/16/2015 01:53 PM, Daniel Golle wrote: > Hi! > > OpenWrt recently switched from using uClibc to musl libc. > This caused a bunch of things in the GNUnet build to break, but it > was all quite easy to fix. > However, I can see that there are a bunch of GNUnet and autotools- > specific hacks which I didn't fully get my head wrapped-around yet, > which is why I simply added some patches to the OpenWrt build, see: > > https://github.com/openwrt/packages/tree/master/net/gnunet/patches > > It'd be great if some GNUnet devs can have a look at the patches so > we can discuss how to properly include them.
Sure, anytime ;-). > 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). > 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. > 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 ;-). > 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. > 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.).
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
