glfw - x11 and opengl

[Carlos Breviglieri]

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

Perhaps the purest way to achieve what I want is to recompile X11 and OGL
with musl-gcc, but I don't think it is a viable alternative, for OGL
depends on the vendor (nvidia/ati/intel/mesa) dynamic libs. I do need to
distribute my software.

Moreover, I must manually tell musl-gcc wrapper to look for X11 and OGL
headers in /usr/include. 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?

Well, I guess it wasn't a quick question after all... I appreciate any
feedback.

Regards,

Carlos


boing: file format elf64-x86-64
boing
architecture: i386:x86-64, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000000000403df0

Program Header:
PHDR off 0x0000000000000040 vaddr 0x0000000000400040 paddr
0x0000000000400040 align 2**3
filesz 0x0000000000000150 memsz 0x0000000000000150 flags r-x
INTERP off 0x0000000000000190 vaddr 0x0000000000400190 paddr
0x0000000000400190 align 2**0
filesz 0x0000000000000055 memsz 0x0000000000000055 flags r--
LOAD off 0x0000000000000000 vaddr 0x0000000000400000 paddr
0x0000000000400000 align 2**21
filesz 0x0000000000012c54 memsz 0x0000000000012c54 flags r-x
LOAD off 0x0000000000013000 vaddr 0x0000000000613000 paddr
0x0000000000613000 align 2**21
filesz 0x0000000000001420 memsz 0x0000000000001e10 flags rw-
DYNAMIC off 0x0000000000013018 vaddr 0x0000000000613018 paddr
0x0000000000613018 align 2**3
filesz 0x0000000000000220 memsz 0x0000000000000220 flags rw-
STACK off 0x0000000000000000 vaddr 0x0000000000000000 paddr
0x0000000000000000 align 2**4
filesz 0x0000000000000000 memsz 0x0000000000000000 flags rw-

Dynamic Section:
NEEDED libm.so.6
NEEDED libGL.so.1
NEEDED libGLU.so.1
NEEDED libX11.so.6
NEEDED libXrandr.so.2
NEEDED libXi.so.6
NEEDED libXxf86vm.so.1
NEEDED libpthread.so.0
NEEDED libc.so.6
INIT 0x0000000000403348
FINI 0x000000000040ff77
INIT_ARRAY 0x0000000000613000
INIT_ARRAYSZ 0x0000000000000008
FINI_ARRAY 0x0000000000613008
FINI_ARRAYSZ 0x0000000000000008
HASH 0x00000000004001e8
STRTAB 0x0000000000401778
SYMTAB 0x00000000004006c8
STRSZ 0x00000000000009fd
SYMENT 0x0000000000000018
DEBUG 0x0000000000000000
PLTGOT 0x0000000000613238
PLTRELSZ 0x0000000000000fd8
PLTREL 0x0000000000000007
JMPREL 0x0000000000402370
VERNEED 0x00000000004022e0
VERNEEDNUM 0x0000000000000003
VERSYM 0x0000000000402176

Version References:
required from libc.so.6:
0x06969194 0x00 07 GLIBC_2.14
0x09691974 0x00 06 GLIBC_2.3.4
0x06969197 0x00 05 GLIBC_2.17
0x09691a75 0x00 04 GLIBC_2.2.5
required from libm.so.6:
0x09691a75 0x00 03 GLIBC_2.2.5
required from libpthread.so.0:
0x09691a75 0x00 02 GLIBC_2.2.5

[Rich Felker]

Post by Carlos Breviglieri
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.

Post by Carlos Breviglieri
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.

Post by Carlos Breviglieri
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

[Carlos Breviglieri]

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

Post by Carlos Breviglieri

Post by Carlos Breviglieri
I develop a numerical simulation software and everything builds nicely

with

Post by Carlos Breviglieri
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

Post by Carlos Breviglieri
(basically OpenGL and custom widget toolkit) which uses glfw (

www.glfw.org).

Post by Carlos Breviglieri
I sucessfully build glfw library using musl-gcc, both as static and

shared

Post by Carlos Breviglieri
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

Post by Carlos Breviglieri
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

Post by Carlos Breviglieri
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

Post by Carlos Breviglieri
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

Post by Carlos Breviglieri
ld-musl-ARCH trickery? I wouldn't like to maintain a mixed build

toolchain

Post by Carlos Breviglieri
(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.

Post by Carlos Breviglieri
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.

Post by Carlos Breviglieri
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

Post by Carlos Breviglieri
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

...

[Laurent Bercot]

I also keep an eye on aboriginal linux for other architectures testings,
which, just now, announced basic musl compatibility... sweet.

Where did you see that announcement ? I can see nothing on landley.net.
I've been waiting for the Aboriginal native musl toolchains for a while
and chafing at the bit. It would be sweet if they were finally ready.
(Rob, can you confirm/deny ?)

[Josiah Worcester]

Post by Laurent Bercot

I also keep an eye on aboriginal linux for other architectures testings,
which, just now, announced basic musl compatibility... sweet.

Where did you see that announcement ? I can see nothing on landley.net.
I've been waiting for the Aboriginal native musl toolchains for a while
and chafing at the bit. It would be sweet if they were finally ready.
(Rob, can you confirm/deny ?)
--
Laurent

The hg repo definitely has initial musl work as of 23 hours ago. It looks
as though it works, but might be fragile and have things not working right.

[Samuel Holland]

Post by Laurent Bercot

I also keep an eye on aboriginal linux for other architectures testings,
which, just now, announced basic musl compatibility... sweet.

Where did you see that announcement ? I can see nothing on landley.net.
I've been waiting for the Aboriginal native musl toolchains for a while
and chafing at the bit. It would be sweet if they were finally ready.
(Rob, can you confirm/deny ?)

http://lists.landley.net/pipermail/aboriginal-landley.net/2014-July/001399.html

[Rich Felker]

Post by Samuel Holland

Post by Laurent Bercot

I also keep an eye on aboriginal linux for other architectures testings,
which, just now, announced basic musl compatibility... sweet.

Where did you see that announcement ? I can see nothing on landley.net.
I've been waiting for the Aboriginal native musl toolchains for a while
and chafing at the bit. It would be sweet if they were finally ready.
(Rob, can you confirm/deny ?)

http://lists.landley.net/pipermail/aboriginal-landley.net/2014-July/001399.html

Has anyone had a chance to look at this yet? It would be nice if
someone with experience with distros/building could help check for
common breakage/pitfalls. I know Aboriginal is using a much older
toolchain than most musl users, so that might also have some new
issues that others haven't encountered. I suspect there might still be
issues with libgcc.a symbol visibility that would result in broken
binaries when dynamic linking against musl; this should be easy to
check.

BTW regarding the libgcc.a issue, since it seems to be common in
bootstrapping, it might be worth working around it in the musl build
process by using -Wl,--exclude-libs,libgcc.a if this option is
supported by the linker.

Anyway back to the point, it's great to see musl making it into
Aboriginal!

Rich

[Isaac Dunham]

Post by Rich Felker

Post by Samuel Holland

Post by Laurent Bercot

I also keep an eye on aboriginal linux for other architectures testings,
which, just now, announced basic musl compatibility... sweet.

Where did you see that announcement ? I can see nothing on landley.net.
I've been waiting for the Aboriginal native musl toolchains for a while
and chafing at the bit. It would be sweet if they were finally ready.
(Rob, can you confirm/deny ?)

http://lists.landley.net/pipermail/aboriginal-landley.net/2014-July/001399.html

Has anyone had a chance to look at this yet? It would be nice if
someone with experience with distros/building could help check for
common breakage/pitfalls. I know Aboriginal is using a much older
toolchain than most musl users, so that might also have some new

...

Similar version (4.2.1) to bootstrap-linux (4.2.2?), also the oldest
supported by musl-cross; I used GCC 3.4 and 4.2.1 with some patches
for the latter from both musl-cross and Aboriginal.

Post by Rich Felker
issues that others haven't encountered. I suspect there might still be
issues with libgcc.a symbol visibility that would result in broken
binaries when dynamic linking against musl; this should be easy to
check.

See the threads of Jan 11/12.
(Rob could not duplicate.)

As far as patches go, he has a number; see
http://landley.net/hg/aboriginal/file/tip/sources/patches
(gcc-core-* is the relevant part).

Post by Rich Felker
BTW regarding the libgcc.a issue, since it seems to be common in
bootstrapping, it might be worth working around it in the musl build
process by using -Wl,--exclude-libs,libgcc.a if this option is
supported by the linker.
Anyway back to the point, it's great to see musl making it into
Aboriginal!

Indeed.

Post by Rich Felker
Rich

Thanks,
Isaac Dunham

[Rich Felker]

Post by Isaac Dunham

Post by Rich Felker

Post by Samuel Holland

Post by Laurent Bercot

I also keep an eye on aboriginal linux for other architectures testings,
which, just now, announced basic musl compatibility... sweet.

Where did you see that announcement ? I can see nothing on landley.net.
I've been waiting for the Aboriginal native musl toolchains for a while
and chafing at the bit. It would be sweet if they were finally ready.
(Rob, can you confirm/deny ?)

http://lists.landley.net/pipermail/aboriginal-landley.net/2014-July/001399.html

Has anyone had a chance to look at this yet? It would be nice if
someone with experience with distros/building could help check for
common breakage/pitfalls. I know Aboriginal is using a much older
toolchain than most musl users, so that might also have some new

Similar version (4.2.1) to bootstrap-linux (4.2.2?), also the oldest
supported by musl-cross; I used GCC 3.4 and 4.2.1 with some patches
for the latter from both musl-cross and Aboriginal.

...

OK good to know.

Post by Isaac Dunham

Post by Rich Felker
issues that others haven't encountered. I suspect there might still be
issues with libgcc.a symbol visibility that would result in broken
binaries when dynamic linking against musl; this should be easy to
check.

See the threads of Jan 11/12.
(Rob could not duplicate.)

Yes, that's why I suspect the bug may still be present: he was only
concerned with finding a test case showing it breaking something and
was not convinced merely by the presence of the visible symbols that
break the ABI.

This is part of why I think it may be beneficial to work around broken
libgcc.a on musl's side: the breakage is subtle when it happens and
it's hard to convince users that there really is a bug.

Rich

[Carlos Breviglieri]

Hey, sorry for the late reply... I saw the announcement at the aboriginal
mailing list and confused it with musl's. The link is already posted, but,
for reference here it goes. You can check out the commits for details at
http://landley.net/hg/aboriginal/rss-log and http://landley.net/notes.html

""""""
Subject: [Aboriginal] basic musl support is in.

To enable it for a given target, comment out the UCLIBC_CONFIG stanza in
the sources/targets/$ARCH file.

All I can really say at the moment is that it compiles for i686. (That's
the ccwrap rewrite, basic script tweaks, and a patch to gcc to not use a
nonstandard type name.)

Sorry that took so long. It was a lot of debugging. (And now to test
build more stuff...)

Rob
""""""

Regards,

Carlos

Post by Carlos Breviglieri

Post by Isaac Dunham

Post by Rich Felker

Post by Laurent Bercot

I also keep an eye on aboriginal linux for other architectures

testings,

Post by Isaac Dunham

Post by Rich Felker

Post by Laurent Bercot

which, just now, announced basic musl compatibility... sweet.

Where did you see that announcement ? I can see nothing on

landley.net.

Post by Isaac Dunham

Post by Rich Felker

Post by Laurent Bercot
I've been waiting for the Aboriginal native musl toolchains for a

while

Post by Isaac Dunham

Post by Rich Felker

Post by Laurent Bercot
and chafing at the bit. It would be sweet if they were finally

ready.

Post by Isaac Dunham

Post by Rich Felker

Post by Laurent Bercot
(Rob, can you confirm/deny ?)

http://lists.landley.net/pipermail/aboriginal-landley.net/2014-July/001399.html

Post by Isaac Dunham

Post by Rich Felker
Has anyone had a chance to look at this yet? It would be nice if
someone with experience with distros/building could help check for
common breakage/pitfalls. I know Aboriginal is using a much older
toolchain than most musl users, so that might also have some new

Similar version (4.2.1) to bootstrap-linux (4.2.2?), also the oldest
supported by musl-cross; I used GCC 3.4 and 4.2.1 with some patches
for the latter from both musl-cross and Aboriginal.

OK good to know.

Post by Isaac Dunham

Post by Rich Felker
issues that others haven't encountered. I suspect there might still be
issues with libgcc.a symbol visibility that would result in broken
binaries when dynamic linking against musl; this should be easy to
check.

See the threads of Jan 11/12.
(Rob could not duplicate.)

Yes, that's why I suspect the bug may still be present: he was only
concerned with finding a test case showing it breaking something and
was not convinced merely by the presence of the visible symbols that
break the ABI.
This is part of why I think it may be beneficial to work around broken
libgcc.a on musl's side: the breakage is subtle when it happens and
it's hard to convince users that there really is a bug.
Rich

...

[Rob Landley]

Post by Rich Felker

Post by Samuel Holland

Post by Laurent Bercot

I also keep an eye on aboriginal linux for other architectures testings,
which, just now, announced basic musl compatibility... sweet.

Where did you see that announcement ? I can see nothing on landley.net.
I've been waiting for the Aboriginal native musl toolchains for a while
and chafing at the bit. It would be sweet if they were finally ready.
(Rob, can you confirm/deny ?)

http://lists.landley.net/pipermail/aboriginal-landley.net/2014-July/001399.html

Has anyone had a chance to look at this yet? It would be nice if
someone with experience with distros/building could help check for
common breakage/pitfalls. I know Aboriginal is using a much older
toolchain than most musl users, so that might also have some new
issues that others haven't encountered. I suspect there might still be
issues with libgcc.a symbol visibility that would result in broken
binaries when dynamic linking against musl; this should be easy to
check.

...

Dynamic linking is indeed broken. Haven't tracked down why yet.
(hello-dynamic works on i686, segfaults on mips.)

Static building seems to work reasonably well though. No sparc support,
but I only ever got 32 bits working there anyway. (Less sad about the
lack of m68k support since there _still_ wasn't a working qemu for that
last I checked.)

Post by Rich Felker
BTW regarding the libgcc.a issue, since it seems to be common in
bootstrapping, it might be worth working around it in the musl build
process by using -Wl,--exclude-libs,libgcc.a if this option is
supported by the linker.

Which libgcc.a issue? I hit a couple different ones, but I think they're
fixed now?

Post by Rich Felker
Anyway back to the point, it's great to see musl making it into
Aboriginal!

Thanks. Sorry it took so long but it's _fiddly_ getting a new toolchain
to work. And I'm sure something else is still lurking somewhere...

Post by Rich Felker
Rich

Rob

[Rich Felker]

Post by Rob Landley

Post by Rich Felker

Post by Samuel Holland

Post by Laurent Bercot

I also keep an eye on aboriginal linux for other architectures testings,
which, just now, announced basic musl compatibility... sweet.

Where did you see that announcement ? I can see nothing on landley.net.
I've been waiting for the Aboriginal native musl toolchains for a while
and chafing at the bit. It would be sweet if they were finally ready.
(Rob, can you confirm/deny ?)

http://lists.landley.net/pipermail/aboriginal-landley.net/2014-July/001399.html

Has anyone had a chance to look at this yet? It would be nice if
someone with experience with distros/building could help check for
common breakage/pitfalls. I know Aboriginal is using a much older
toolchain than most musl users, so that might also have some new
issues that others haven't encountered. I suspect there might still be
issues with libgcc.a symbol visibility that would result in broken
binaries when dynamic linking against musl; this should be easy to
check.

Dynamic linking is indeed broken. Haven't tracked down why yet.
(hello-dynamic works on i686, segfaults on mips.)

...

Is it only mips that's segfaulting, or other archs too? I'm guessing
it's either an issue with your toolchain, or perhaps the mips
relocation regression in 1.1.3 that's fixed in master -- it was
announced here on the list.

Post by Rob Landley

Post by Rich Felker
BTW regarding the libgcc.a issue, since it seems to be common in
bootstrapping, it might be worth working around it in the musl build
process by using -Wl,--exclude-libs,libgcc.a if this option is
supported by the linker.

Which libgcc.a issue? I hit a couple different ones, but I think they're
fixed now?

Any libgcc-namespace symbols (like __udivdi3) getting exported from
musl libc.so. This command should show some of them if they're
present:

nm -D lib/libc.so | grep __.*div

Rich