[Top][All Lists]

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

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

From: Daniel Golle
Subject: Re: [GNUnet-developers] building on OpenWrt with musl
Date: Wed, 17 Jun 2015 15:35:48 +0200
User-agent: Mutt/1.5.23+89 (0255b37be491) (2014-03-12)


On Wed, Jun 17, 2015 at 11:13:48AM +0200, Christian Grothoff wrote:
> > 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 ;-).

Nice, good to have at some people still able to debug mor subtle
autotools bugs...
It seems to work now, thanks for fixing!

> ...

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

I was talking about mbedtls = PolarSSL, just didn't get their new name

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

That's why I do patch libgnurl.m4 in

OpenWrt also supports parallel builds utilizing the make job
server, thus there is no guarantee that curl is built before gnurl,
thus both packages would have to check for the headers already being
installed by either of them... That would again require to patch the
curl package to be aware of libgnurl which is not an option, as gnurl
is part of the community maintained packages feed on github while
curl is part of OpenWrt's core packages...

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

As said above, detecting already present headers cannot work reliable
in parallel builds, unless gnurl makes sure that curl is built no
matter what by build-depending on it, which makes that solution less
nice compared to patching the project sources not to require curl
to be build at all (which is what I'm doing for now).

Wouldn't it be possible to have autotools detect whether gnurl/curl
headers are present in either possible path and set precompiler
macros accordingly...?



reply via email to

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