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 _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
