[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 3 Jul 2014 18:22:26 -0300
From: Carlos Breviglieri <carbrevi@...il.com>
To: musl@...ts.openwall.com
Subject: Re: glfw - x11 and opengl
Rich, thanks for clarifying those points.
I believe the reasonable approach now is to use musl on the numerical side
of things and leave the more system-wide apps (GUI) using the default libc.
The whole point of this exercise is to evaluate the benefits of static
linking with numerical intensive computations, possibly in parallel
(clusters). And that does not involve the graphical side of things.
I didn't know of lxc and it looks interesting to research latter.. I also
keep an eye on aboriginal linux for other architectures testings, which,
just now, announced basic musl compatibility... sweet.
Thanks,
Carlos Breviglieri
Instituto Tecnologico de Aeronautica
Brazil
On Thu, Jul 3, 2014 at 5:50 PM, Rich Felker <dalias@...c.org> wrote:
> On Thu, Jul 03, 2014 at 04:16:54PM -0300, Carlos Breviglieri wrote:
> > Hi there, I have a quick, basic user question:
> >
> > I develop a numerical simulation software and everything builds nicely
> with
> > musl (ok, had to patch some pkgs - hdf5, mpich3, cgns, libscotch). In the
> > end I want to research how static/shared vs gnu/musl affects runtime and
> > efficiency of the numerical solver. My software also has an user
> interface
> > (basically OpenGL and custom widget toolkit) which uses glfw (
> www.glfw.org).
> >
> > I sucessfully build glfw library using musl-gcc, both as static and
> shared
> > lib. However, the example binaries and my GUI need linking to X11 and
> > OpenGL (OGL) libs. The problem is that, in my system (Arch linux) and
> most
> > distros I can think of, X11 and OpenGL are dynamic libs that use gnu
> > libc.so (ldd shows that).
> >
> > My question is: Is it possible to "tell" libX11.so and libGL.so to use
> musl
> > libc.so instead, you know at runtime? I tried the LD_PRELOAD trick and it
> > didn't work (ldd on executable prints lots of empty lines...). A portion
> of
> > the output of "objdump -x" is below.
> >
> > I understand that musl libc might not be 100% compatible with gnu libc if
> > such thing is possible... Just trying to grasp the possibility. Maybe
> some
> > ld-musl-ARCH trickery? I wouldn't like to maintain a mixed build
> toolchain
> > (musl for the numerical package and gnu libc for the GUI stuff).
>
> In general, you want to avoid doing this. The goal is to eventually
> have enough compatibility to get most "important" binary-only modules
> that people actually want to use to work, and whatever else is easy,
> but the more glibc-linked libraries you try to use, the more chance
> there is for things to go spectacularly wrong.
>
> Ideally you should have a full set of musl-linked library files for
> all of the ones that are open source, and only attempt to use binary
> compatibility for the few that you can't recompile or get musl-native
> versions for.
>
> > Moreover, I must manually tell musl-gcc wrapper to look for X11 and OGL
> > headers in /usr/include.
>
> The whole point of the musl-gcc wrapper is to prevent gcc from looking
> in /usr/include, /usr/lib, etc.
>
> > Obviously it finds gnu libc include folder and mix
> > things to a failed compilation. I circunvented this problem by creating
> > soft links to X11 and GL headers folders into another path and include
> that
> > path during compilation. Any better/correct way to do this?
>
> Yes, building them against musl and installing them in the same
> alternate prefix you installed musl in.
>
> Alternatively, you might try using a musl-based distro like Alpine,
> possibly inside your regular distro by means of lxc.
>
> Rich
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
