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: Tue, 16 Jun 2015 23:48:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0

Hi again!

On 06/16/2015 03:51 PM, Daniel Golle wrote:
> 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.

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)?

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

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):

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

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

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

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

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

Happy hacking!

Christian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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