mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Wermut <wermut@gmail.com>
To: "musl@lists.openwall.com" <musl@lists.openwall.com>
Subject: Re: libhybris and musl?
Date: Tue, 2 Sep 2014 09:11:33 +0200	[thread overview]
Message-ID: <CALONj1fbjsRY7_NUeLW4EWJwGHnXpqUZVMO9uDtm2e4dnADP3w@mail.gmail.com> (raw)
In-Reply-To: <20140901210823.GF12888@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]

We used libhybris for one single thing. Getting Android/bionic linked
graphic drivers up and running under embedded glibc linux. Since all the
hardware vendors startet to only deliver their drivers in binary form and
exclusivly for Android, these is usually the only way to get GPU up and
running.

libhybris was originally developed for Sailfish OS that is using Android
drivers of all kind under a glibc enviroment. The graphic Stack is Android
OpenGL driver > libhybris > wayland. Other projects like the Intel/Samsung
"mer" project is doing exactly the same.

If you are interessted how to install and use it, there is a rudimentary
how to:
http://www.cnx-software.com/2013/04/21/how-to-use-libhybris-and-android-gpu-libraries-with-mer-linux-on-the-cubieboard/

This thing is a therible hack, but unfortunatly this is often the only way
to get things like OpenGL, hw video decoding etc. working on embedded arm
linux. There are no signs that companies like Qualcom or ARM themself with
their Mali GPU will deliver open source drivers.

Linking your own apps to bionic/libhybris makes absolutly no sense. The
reason for libhybris is to use bionic binaries (drivers) within glibc based
enviroments.


On Mon, Sep 1, 2014 at 11:08 PM, Rich Felker <dalias@libc.org> wrote:

> On Mon, Sep 01, 2014 at 10:55:26AM +0200, Jens Staal wrote:
> > Hi
> >
> > Has anyone tried if libhybris will emulate the bionic libc properly on
> top of
> > musl libc? Alternatively, are there plans for bionic binary/source
> > compatibility in musl like the glibc compatibility (or would this
> contribute
> > to bloat?).
> >
> > I was mostly curious to look into the possiblility of building AOSP (or
> Mer)
> > with musl instead of bionic (or glibc in the case of Mer), but for
> Android app
> > (those built with NDK) compatibility, one would then need libhybris.
> >
> > right now just thinking aloud - no real plans at the moment :)
>
> While I haven't look at the details for how it works, I'm fairly
> doubtful that using libhybris would be practical. My guess is that
> you'll find it fairly glibc-specific, but perhaps more importantly I'm
> not sure what benefit you would get from having apps built against
> Bionic using musl. If you have particular aims in mind, let me know,
> but my feeling is that it would be a lot more practical to just fix up
> the things Bionic is doing that are gratuitously different/broken to
> get to a point where programs using Bionic run cleanly side by side
> with musl. But if the issue is binary apps using native NDK code with
> the Bionic ABI, but where you want the non-native code to run on a
> musl-linked Dalvik rather than a Bionic-linked one, and if this all
> takes place in the same process context, then maybe something like
> libhybris really is needed.
>
> I'm quite interested in this project as a prototype for how Android
> could be moved from Bionic to musl, and (optionally, but I think this
> is the right direction) steered back from its gratuitous
> incompatibilities in filesystem layout, handling of dns, user/group
> lookups, etc. and re-unified with Linux. Please keep us informed if
> you make any interesting progress!
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 3997 bytes --]

  reply	other threads:[~2014-09-02  7:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-01  8:55 Jens Staal
2014-09-01 21:08 ` Rich Felker
2014-09-02  7:11   ` Wermut [this message]
2014-09-02  8:34     ` Rich Felker
2014-09-02  9:25       ` Wermut
2014-09-03 22:35         ` Rich Felker
2014-09-03 22:59   ` Rich Felker
2014-09-04 15:17     ` Isaac Dunham
2014-09-04 15:55       ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALONj1fbjsRY7_NUeLW4EWJwGHnXpqUZVMO9uDtm2e4dnADP3w@mail.gmail.com \
    --to=wermut@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).