* glfw - x11 and opengl @ 2014-07-03 19:16 Carlos Breviglieri 2014-07-03 20:50 ` Rich Felker 0 siblings, 1 reply; 12+ messages in thread From: Carlos Breviglieri @ 2014-07-03 19:16 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 4606 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 5681 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: glfw - x11 and opengl 2014-07-03 19:16 glfw - x11 and opengl Carlos Breviglieri @ 2014-07-03 20:50 ` Rich Felker 2014-07-03 21:22 ` Carlos Breviglieri 0 siblings, 1 reply; 12+ messages in thread From: Rich Felker @ 2014-07-03 20:50 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: glfw - x11 and opengl 2014-07-03 20:50 ` Rich Felker @ 2014-07-03 21:22 ` Carlos Breviglieri 2014-07-04 0:14 ` Laurent Bercot 0 siblings, 1 reply; 12+ messages in thread From: Carlos Breviglieri @ 2014-07-03 21:22 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 3527 bytes --] 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@libc.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 > [-- Attachment #2: Type: text/html, Size: 4351 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: glfw - x11 and opengl 2014-07-03 21:22 ` Carlos Breviglieri @ 2014-07-04 0:14 ` Laurent Bercot 2014-07-04 0:21 ` Josiah Worcester 2014-07-04 2:40 ` Samuel Holland 0 siblings, 2 replies; 12+ messages in thread From: Laurent Bercot @ 2014-07-04 0:14 UTC (permalink / raw) To: musl On 03/07/2014 22:22, Carlos Breviglieri wrote: > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: glfw - x11 and opengl 2014-07-04 0:14 ` Laurent Bercot @ 2014-07-04 0:21 ` Josiah Worcester 2014-07-04 2:40 ` Samuel Holland 1 sibling, 0 replies; 12+ messages in thread From: Josiah Worcester @ 2014-07-04 0:21 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 697 bytes --] On Jul 3, 2014 7:14 PM, "Laurent Bercot" <ska-dietlibc@skarnet.org> wrote: > > On 03/07/2014 22:22, Carlos Breviglieri wrote: >> >> 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. [-- Attachment #2: Type: text/html, Size: 952 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: glfw - x11 and opengl 2014-07-04 0:14 ` Laurent Bercot 2014-07-04 0:21 ` Josiah Worcester @ 2014-07-04 2:40 ` Samuel Holland 2014-07-04 3:25 ` Rich Felker 1 sibling, 1 reply; 12+ messages in thread From: Samuel Holland @ 2014-07-04 2:40 UTC (permalink / raw) To: musl On Fri, 2014-07-04 at 01:14 +0100, Laurent Bercot wrote: > On 03/07/2014 22:22, Carlos Breviglieri wrote: > > 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 -- Regards, Samuel Holland <samuel@sholland.net> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: glfw - x11 and opengl 2014-07-04 2:40 ` Samuel Holland @ 2014-07-04 3:25 ` Rich Felker 2014-07-04 5:19 ` Aboriginal musl support Isaac Dunham 2014-07-08 0:38 ` glfw - x11 and opengl Rob Landley 0 siblings, 2 replies; 12+ messages in thread From: Rich Felker @ 2014-07-04 3:25 UTC (permalink / raw) To: musl On Thu, Jul 03, 2014 at 09:40:10PM -0500, Samuel Holland wrote: > On Fri, 2014-07-04 at 01:14 +0100, Laurent Bercot wrote: > > On 03/07/2014 22:22, Carlos Breviglieri wrote: > > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Aboriginal musl support 2014-07-04 3:25 ` Rich Felker @ 2014-07-04 5:19 ` Isaac Dunham 2014-07-04 5:46 ` Rich Felker 2014-07-08 0:38 ` glfw - x11 and opengl Rob Landley 1 sibling, 1 reply; 12+ messages in thread From: Isaac Dunham @ 2014-07-04 5:19 UTC (permalink / raw) To: musl On Thu, Jul 03, 2014 at 11:25:46PM -0400, Rich Felker wrote: > On Thu, Jul 03, 2014 at 09:40:10PM -0500, Samuel Holland wrote: > > On Fri, 2014-07-04 at 01:14 +0100, Laurent Bercot wrote: > > > On 03/07/2014 22:22, Carlos Breviglieri wrote: > > > > 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. > 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). > 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. > Rich Thanks, Isaac Dunham ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Aboriginal musl support 2014-07-04 5:19 ` Aboriginal musl support Isaac Dunham @ 2014-07-04 5:46 ` Rich Felker 2014-07-04 12:33 ` Carlos Breviglieri 0 siblings, 1 reply; 12+ messages in thread From: Rich Felker @ 2014-07-04 5:46 UTC (permalink / raw) To: musl On Sat, Jul 05, 2014 at 11:18:29PM -0700, Isaac Dunham wrote: > On Thu, Jul 03, 2014 at 11:25:46PM -0400, Rich Felker wrote: > > On Thu, Jul 03, 2014 at 09:40:10PM -0500, Samuel Holland wrote: > > > On Fri, 2014-07-04 at 01:14 +0100, Laurent Bercot wrote: > > > > On 03/07/2014 22:22, Carlos Breviglieri wrote: > > > > > 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. > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Aboriginal musl support 2014-07-04 5:46 ` Rich Felker @ 2014-07-04 12:33 ` Carlos Breviglieri 0 siblings, 0 replies; 12+ messages in thread From: Carlos Breviglieri @ 2014-07-04 12:33 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 2986 bytes --] 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 On Fri, Jul 4, 2014 at 2:46 AM, Rich Felker <dalias@libc.org> wrote: > On Sat, Jul 05, 2014 at 11:18:29PM -0700, Isaac Dunham wrote: > > On Thu, Jul 03, 2014 at 11:25:46PM -0400, Rich Felker wrote: > > > On Thu, Jul 03, 2014 at 09:40:10PM -0500, Samuel Holland wrote: > > > > On Fri, 2014-07-04 at 01:14 +0100, Laurent Bercot wrote: > > > > > On 03/07/2014 22:22, Carlos Breviglieri wrote: > > > > > > 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. > > > > 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 > [-- Attachment #2: Type: text/html, Size: 4181 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: glfw - x11 and opengl 2014-07-04 3:25 ` Rich Felker 2014-07-04 5:19 ` Aboriginal musl support Isaac Dunham @ 2014-07-08 0:38 ` Rob Landley 2014-07-08 0:43 ` Rich Felker 1 sibling, 1 reply; 12+ messages in thread From: Rob Landley @ 2014-07-08 0:38 UTC (permalink / raw) To: musl On 07/03/14 22:25, Rich Felker wrote: > On Thu, Jul 03, 2014 at 09:40:10PM -0500, Samuel Holland wrote: >> On Fri, 2014-07-04 at 01:14 +0100, Laurent Bercot wrote: >>> On 03/07/2014 22:22, Carlos Breviglieri wrote: >>>> 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.) > 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? > 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... > Rich Rob ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: glfw - x11 and opengl 2014-07-08 0:38 ` glfw - x11 and opengl Rob Landley @ 2014-07-08 0:43 ` Rich Felker 0 siblings, 0 replies; 12+ messages in thread From: Rich Felker @ 2014-07-08 0:43 UTC (permalink / raw) To: musl On Mon, Jul 07, 2014 at 07:38:26PM -0500, Rob Landley wrote: > On 07/03/14 22:25, Rich Felker wrote: > > On Thu, Jul 03, 2014 at 09:40:10PM -0500, Samuel Holland wrote: > >> On Fri, 2014-07-04 at 01:14 +0100, Laurent Bercot wrote: > >>> On 03/07/2014 22:22, Carlos Breviglieri wrote: > >>>> 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. > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-07-08 0:43 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-07-03 19:16 glfw - x11 and opengl Carlos Breviglieri 2014-07-03 20:50 ` Rich Felker 2014-07-03 21:22 ` Carlos Breviglieri 2014-07-04 0:14 ` Laurent Bercot 2014-07-04 0:21 ` Josiah Worcester 2014-07-04 2:40 ` Samuel Holland 2014-07-04 3:25 ` Rich Felker 2014-07-04 5:19 ` Aboriginal musl support Isaac Dunham 2014-07-04 5:46 ` Rich Felker 2014-07-04 12:33 ` Carlos Breviglieri 2014-07-08 0:38 ` glfw - x11 and opengl Rob Landley 2014-07-08 0:43 ` Rich Felker
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).