Re: libhybris and musl?

[Wermut <wermut@gmail.com>]

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

I think the following blog post explains the concept nicely:
http://groleo.wordpress.com/2013/07/22/brief-intro-to-libhybris/

I simply overrites the bionic symbols and provides glibc compatible calls.
This solution works very nicely, but can have problems if threading is
involved.

Also good references from the original creator of libhybris:
http://mer-project.blogspot.fi/2013/04/wayland-utilizing-android-gpu-drivers.html
http://mer-project.blogspot.fi/2013/05/wayland-utilizing-android-gpu-drivers.html



On Tue, Sep 2, 2014 at 10:34 AM, Rich Felker <dalias@libc.org> wrote:

> On Tue, Sep 02, 2014 at 09:11:33AM +0200, Wermut wrote:
> > 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.
>
> How does this work when the binary driver is accessing the same symbol
> names (mainly standard functions, but not necessarily) as the program
> the driver is loaded into, but the latter needs the real versions in
> libc and only the former should be routed through a hack layer?
>
> Rich
>

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