[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: Sun, 21 Jun 2015 18:17:42 +0200
User-agent: Mutt/1.5.23+89 (0255b37be491) (2014-03-12)

Hi Christian,

On Sun, Jun 21, 2015 at 01:06:12PM +0200, Christian Grothoff wrote:
> On 06/17/2015 03:35 PM, Daniel Golle wrote:
> > Wouldn't it be possible to have autotools detect whether gnurl/curl
> > headers are present in either possible path and set precompiler
> > macros accordingly...?
> > 
> Code should be fixed to do this as of SVN 35963. Please let me know if
> it doesn't work (with config.log output).

Wow, not a single out-of-tree patch left in the OpenWrt package build,
I just removed the last dirty patch!

Now only these two changes needs to be discussed with and merged by the
respective package maintainers, libmicrohttpd and libarchive which is
used by libextractor.

Next step would be to define meta-packages for common use-cases in
order to have users start-off with a default pre-selection of
libextractor plugins and gstreamer modules...

It's been great helping out packaging and cross-building GNUnet so far,
I'm amazed by the speed the GNUnet team gets things done! Feels like
you are just as excited about the project as if it started just
yesterday ;)

I also did some homework and extended the GNUnet package to also build
the mysql and postgresql database backends available.

I'm happy to see PostgreSQL support being quite complete as that's good
news for performance on machines which do have more storage than RAM.

On smaller boxes (routers) I'm still dreaming about using cadet and GNS
without needing to deploy libsqlite which is not the ideal tool when
having only a small amount of RAM and practically no storage at all...

There is one more thing I'm not sure about:
I noticed earlier that gnunet-conversation can build against both,
libpulse and gstreamer.
However, the prefix for pulse cannot be passed to configure, so I
currently work-around that by setting -Wl,rpath-link=... in
TARGET_CLFAGS which does the job:

Looking at the code I understand that either gstreamer OR direct
use of libpulse, libopus and libogg can provide audio playback
and recording.

Are both A(/V) backends equally well maintained?

For OpenWrt, it'd be nice to have them packaged seperately.
Both backends equally can make sense, depending on if reuse
of gstreamer libs by many apps justisfies its overhead.



reply via email to

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