* musl & proprietary programs @ 2015-12-22 11:23 Alba Pompeo 2015-12-22 11:27 ` Timo Teras 0 siblings, 1 reply; 19+ messages in thread From: Alba Pompeo @ 2015-12-22 11:23 UTC (permalink / raw) To: musl 'Morning developers, As a user, my main issue with musl by far is the lack of ability to run proprietary programs. Almost all software I need for work is proprietary and I currently have to dual boot other operating system just to run it, because there is no musl binary. Is there any strategy to get musl to be more useful on proprietary environments? Either partnerships with some companies to spread musl or a compatibility mode that you can use when needed? This would be of great help for those that unfortunately aren't on the ideal world where every tool has the source available for you to compile. Ciao. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-22 11:23 musl & proprietary programs Alba Pompeo @ 2015-12-22 11:27 ` Timo Teras 2015-12-22 15:25 ` Рысь 0 siblings, 1 reply; 19+ messages in thread From: Timo Teras @ 2015-12-22 11:27 UTC (permalink / raw) To: Alba Pompeo; +Cc: musl On Tue, 22 Dec 2015 09:23:08 -0200 Alba Pompeo <albapompeo@gmail.com> wrote: > As a user, my main issue with musl by far is the lack of ability to > run proprietary programs. Almost all software I need for work is > proprietary and I currently have to dual boot other operating system > just to run it, because there is no musl binary. > > Is there any strategy to get musl to be more useful on proprietary > environments? Either partnerships with some companies to spread musl > or a compatibility mode that you can use when needed? This would be of > great help for those that unfortunately aren't on the ideal world > where every tool has the source available for you to compile. Musl works with surprisingly many proprietary programs. Could you explain more the problem you have? Though, you you do have to have symlinks for the glibc style library names for things to work. In Alpine Linux these comes with "apk add libc6-compat". /Timo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-22 11:27 ` Timo Teras @ 2015-12-22 15:25 ` Рысь 2015-12-22 15:37 ` Alba Pompeo 0 siblings, 1 reply; 19+ messages in thread From: Рысь @ 2015-12-22 15:25 UTC (permalink / raw) To: musl On Tue, 22 Dec 2015 13:27:06 +0200 Timo Teras <timo.teras@iki.fi> wrote: > On Tue, 22 Dec 2015 09:23:08 -0200 > Alba Pompeo <albapompeo@gmail.com> wrote: > > > As a user, my main issue with musl by far is the lack of ability to > > run proprietary programs. Almost all software I need for work is > > proprietary and I currently have to dual boot other operating system > > just to run it, because there is no musl binary. > > > > Is there any strategy to get musl to be more useful on proprietary > > environments? Either partnerships with some companies to spread musl > > or a compatibility mode that you can use when needed? This would be > > of great help for those that unfortunately aren't on the ideal world > > where every tool has the source available for you to compile. > > Musl works with surprisingly many proprietary programs. Could you > explain more the problem you have? > > Though, you you do have to have symlinks for the glibc style library > names for things to work. > > In Alpine Linux these comes with "apk add libc6-compat". > > /Timo I can also suggest building chroots from existing glibc distributions. For example, one can get full Slackware DVD, unpack it fully or partially and use the result root as chroot tree and put a program inside it. Though there is little help needed to define proper symlinks to unpacked shared objects. This can be achieved with simple script employing readelf or running glibc's ldconfig inside chroot. This method is IMO more cleaner when you want to run glibc programs completely unmodified. Missing virtual filesystems and locations with user data can be bind-mounted. -- http://lynxlynx.tk/ Power electronics made simple Unix and simple KISS C code ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-22 15:25 ` Рысь @ 2015-12-22 15:37 ` Alba Pompeo 2015-12-23 14:48 ` Szabolcs Nagy 0 siblings, 1 reply; 19+ messages in thread From: Alba Pompeo @ 2015-12-22 15:37 UTC (permalink / raw) To: musl chroot is a little better than dual-boot, but still very unfriendly for a day-to-day usage of many proprietary tools. On Tue, Dec 22, 2015 at 1:25 PM, Рысь <lynx@lynxlynx.tk> wrote: > On Tue, 22 Dec 2015 13:27:06 +0200 > Timo Teras <timo.teras@iki.fi> wrote: > >> On Tue, 22 Dec 2015 09:23:08 -0200 >> Alba Pompeo <albapompeo@gmail.com> wrote: >> >> > As a user, my main issue with musl by far is the lack of ability to >> > run proprietary programs. Almost all software I need for work is >> > proprietary and I currently have to dual boot other operating system >> > just to run it, because there is no musl binary. >> > >> > Is there any strategy to get musl to be more useful on proprietary >> > environments? Either partnerships with some companies to spread musl >> > or a compatibility mode that you can use when needed? This would be >> > of great help for those that unfortunately aren't on the ideal world >> > where every tool has the source available for you to compile. >> >> Musl works with surprisingly many proprietary programs. Could you >> explain more the problem you have? >> >> Though, you you do have to have symlinks for the glibc style library >> names for things to work. >> >> In Alpine Linux these comes with "apk add libc6-compat". >> >> /Timo > > I can also suggest building chroots from existing glibc distributions. > For example, one can get full Slackware DVD, unpack it fully or > partially and use the result root as chroot tree and put a program > inside it. Though there is little help needed to define proper symlinks > to unpacked shared objects. This can be achieved with simple script > employing readelf or running glibc's ldconfig inside chroot. > > This method is IMO more cleaner when you want to run glibc programs > completely unmodified. Missing virtual filesystems and locations with > user data can be bind-mounted. > > -- > http://lynxlynx.tk/ > Power electronics made simple > Unix and simple KISS C code ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-22 15:37 ` Alba Pompeo @ 2015-12-23 14:48 ` Szabolcs Nagy 2015-12-23 16:01 ` u-uy74 2015-12-23 17:22 ` Рысь 0 siblings, 2 replies; 19+ messages in thread From: Szabolcs Nagy @ 2015-12-23 14:48 UTC (permalink / raw) To: musl * Alba Pompeo <albapompeo@gmail.com> [2015-12-22 13:37:52 -0200]: > chroot is a little better than dual-boot, but still very unfriendly > for a day-to-day usage of many proprietary tools. > on x86, binaries linked against glibc can be made to work with musl. but isolating such software into a separate virtual environment is a good idea anyway and then it's easier to use glibc based userspace there. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-23 14:48 ` Szabolcs Nagy @ 2015-12-23 16:01 ` u-uy74 2015-12-23 17:22 ` Рысь 1 sibling, 0 replies; 19+ messages in thread From: u-uy74 @ 2015-12-23 16:01 UTC (permalink / raw) To: musl On Wed, Dec 23, 2015 at 03:48:53PM +0100, Szabolcs Nagy wrote: > * Alba Pompeo <albapompeo@gmail.com> [2015-12-22 13:37:52 -0200]: > > chroot is a little better than dual-boot, but still very unfriendly > > for a day-to-day usage of many proprietary tools. > > > > on x86, binaries linked against glibc can be made to work with > musl. > > but isolating such software into a separate virtual environment > is a good idea anyway and then it's easier to use glibc based > userspace there. Proot comes to mind (http://proot.me/) which looks like just the right tool for the purpose. Rune ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-23 14:48 ` Szabolcs Nagy 2015-12-23 16:01 ` u-uy74 @ 2015-12-23 17:22 ` Рысь 2015-12-23 17:43 ` Rich Felker 1 sibling, 1 reply; 19+ messages in thread From: Рысь @ 2015-12-23 17:22 UTC (permalink / raw) To: musl On Wed, 23 Dec 2015 15:48:53 +0100 Szabolcs Nagy <nsz@port70.net> wrote: > * Alba Pompeo <albapompeo@gmail.com> [2015-12-22 13:37:52 -0200]: > > chroot is a little better than dual-boot, but still very unfriendly > > for a day-to-day usage of many proprietary tools. > > > > on x86, binaries linked against glibc can be made to work with > musl. > > but isolating such software into a separate virtual environment > is a good idea anyway and then it's easier to use glibc based > userspace there. Well that's fine until you will not face something dynamic. A simple example: some of my machines successfully runs LibreOffice 4 inside Slackware 14 chroot. Problems start when user wants to save a document to USB stick. This is a valid use case, but fails because you end up with mounting USB stick twice. This requires wrappers. And in *DE environments they will be lost under pressure of various mount daemons or something like that. But at rest, it works flawlessly. Maybe Alba Pompeo just faces an issue with wide filesystem tree that needs to be inside chroot. -- http://lynxlynx.tk/ Power electronics made simple Unix and simple KISS C code ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-23 17:22 ` Рысь @ 2015-12-23 17:43 ` Rich Felker 2015-12-23 18:51 ` Рысь 0 siblings, 1 reply; 19+ messages in thread From: Rich Felker @ 2015-12-23 17:43 UTC (permalink / raw) To: musl On Thu, Dec 24, 2015 at 12:22:05AM +0700, Рысь wrote: > On Wed, 23 Dec 2015 15:48:53 +0100 > Szabolcs Nagy <nsz@port70.net> wrote: > > > * Alba Pompeo <albapompeo@gmail.com> [2015-12-22 13:37:52 -0200]: > > > chroot is a little better than dual-boot, but still very unfriendly > > > for a day-to-day usage of many proprietary tools. > > > > > > > on x86, binaries linked against glibc can be made to work with > > musl. > > > > but isolating such software into a separate virtual environment > > is a good idea anyway and then it's easier to use glibc based > > userspace there. > > Well that's fine until you will not face something dynamic. A simple > example: some of my machines successfully runs LibreOffice 4 inside > Slackware 14 chroot. Problems start when user wants to save a document > to USB stick. This is a valid use case, but fails because you end up > with mounting USB stick twice. This requires wrappers. And in *DE > environments they will be lost under pressure of various mount daemons > or something like that. But at rest, it works flawlessly. > > Maybe Alba Pompeo just faces an issue with wide filesystem tree that > needs to be inside chroot. I don't see why chroot is necessary at all. If you want a glibc environment for a single app you can put all the glibc stuff in its own library path and either invoke the binary manually using the glibc dynamic linker or have (a symlink to) the glibc dynamic linker in /lib. Then it can access the normal filesystem just fine. Containers (or just chroot) are of course preferable when you actually do want to isolate the program for trust/privilege purposes, but they're not a technical requirement for running foreign-libc binaries. Rich ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-23 17:43 ` Rich Felker @ 2015-12-23 18:51 ` Рысь 2015-12-23 20:00 ` Alba Pompeo 2015-12-24 5:12 ` Rich Felker 0 siblings, 2 replies; 19+ messages in thread From: Рысь @ 2015-12-23 18:51 UTC (permalink / raw) To: musl On Wed, 23 Dec 2015 12:43:52 -0500 Rich Felker <dalias@libc.org> wrote: > On Thu, Dec 24, 2015 at 12:22:05AM +0700, Рысь wrote: > > On Wed, 23 Dec 2015 15:48:53 +0100 > > Szabolcs Nagy <nsz@port70.net> wrote: > > > > > * Alba Pompeo <albapompeo@gmail.com> [2015-12-22 13:37:52 -0200]: > > > > chroot is a little better than dual-boot, but still very > > > > unfriendly for a day-to-day usage of many proprietary tools. > > > > > > > > > > on x86, binaries linked against glibc can be made to work with > > > musl. > > > > > > but isolating such software into a separate virtual environment > > > is a good idea anyway and then it's easier to use glibc based > > > userspace there. > > > > Well that's fine until you will not face something dynamic. A simple > > example: some of my machines successfully runs LibreOffice 4 inside > > Slackware 14 chroot. Problems start when user wants to save a > > document to USB stick. This is a valid use case, but fails because > > you end up with mounting USB stick twice. This requires wrappers. > > And in *DE environments they will be lost under pressure of various > > mount daemons or something like that. But at rest, it works > > flawlessly. > > > > Maybe Alba Pompeo just faces an issue with wide filesystem tree that > > needs to be inside chroot. > > I don't see why chroot is necessary at all. If you want a glibc > environment for a single app you can put all the glibc stuff in its > own library path and either invoke the binary manually using the glibc > dynamic linker or have (a symlink to) the glibc dynamic linker in > /lib. Then it can access the normal filesystem just fine. > > Containers (or just chroot) are of course preferable when you actually > do want to isolate the program for trust/privilege purposes, but > they're not a technical requirement for running foreign-libc binaries. > > Rich And glibc will not pickup random musl linked shared objects from standard paths (/lib:/usr/lib) from host? To be honest, I did not even tried just because I do not want to pollute my systems with glibc. -- http://lynxlynx.tk/ Power electronics made simple Unix and simple KISS C code ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-23 18:51 ` Рысь @ 2015-12-23 20:00 ` Alba Pompeo 2015-12-24 5:04 ` Рысь 2015-12-24 7:00 ` Isaac Dunham 2015-12-24 5:12 ` Rich Felker 1 sibling, 2 replies; 19+ messages in thread From: Alba Pompeo @ 2015-12-23 20:00 UTC (permalink / raw) To: musl I also don't want to pollute my system with glibc. That's why I asked if there was any plan to improve musl support of proprietary programs like the ones I listed. But as a last resort, I think Rich's method is the best so far, but I'm a bit lost on the details since I'm not a libc expert. I couldn't find a wiki page detailing Rich's method on Void or Alpine (the 2 distros I know use musl). Is there a step-by-step for a novice somewhere? On Wed, Dec 23, 2015 at 4:51 PM, Рысь <lynx@lynxlynx.tk> wrote: > On Wed, 23 Dec 2015 12:43:52 -0500 > Rich Felker <dalias@libc.org> wrote: > >> On Thu, Dec 24, 2015 at 12:22:05AM +0700, Рысь wrote: >> > On Wed, 23 Dec 2015 15:48:53 +0100 >> > Szabolcs Nagy <nsz@port70.net> wrote: >> > >> > > * Alba Pompeo <albapompeo@gmail.com> [2015-12-22 13:37:52 -0200]: >> > > > chroot is a little better than dual-boot, but still very >> > > > unfriendly for a day-to-day usage of many proprietary tools. >> > > > >> > > >> > > on x86, binaries linked against glibc can be made to work with >> > > musl. >> > > >> > > but isolating such software into a separate virtual environment >> > > is a good idea anyway and then it's easier to use glibc based >> > > userspace there. >> > >> > Well that's fine until you will not face something dynamic. A simple >> > example: some of my machines successfully runs LibreOffice 4 inside >> > Slackware 14 chroot. Problems start when user wants to save a >> > document to USB stick. This is a valid use case, but fails because >> > you end up with mounting USB stick twice. This requires wrappers. >> > And in *DE environments they will be lost under pressure of various >> > mount daemons or something like that. But at rest, it works >> > flawlessly. >> > >> > Maybe Alba Pompeo just faces an issue with wide filesystem tree that >> > needs to be inside chroot. >> >> I don't see why chroot is necessary at all. If you want a glibc >> environment for a single app you can put all the glibc stuff in its >> own library path and either invoke the binary manually using the glibc >> dynamic linker or have (a symlink to) the glibc dynamic linker in >> /lib. Then it can access the normal filesystem just fine. >> >> Containers (or just chroot) are of course preferable when you actually >> do want to isolate the program for trust/privilege purposes, but >> they're not a technical requirement for running foreign-libc binaries. >> >> Rich > > And glibc will not pickup random musl linked shared objects from > standard paths (/lib:/usr/lib) from host? To be honest, I did not even > tried just because I do not want to pollute my systems with glibc. > > -- > http://lynxlynx.tk/ > Power electronics made simple > Unix and simple KISS C code ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-23 20:00 ` Alba Pompeo @ 2015-12-24 5:04 ` Рысь 2015-12-24 5:16 ` Rich Felker 2015-12-24 7:00 ` Isaac Dunham 1 sibling, 1 reply; 19+ messages in thread From: Рысь @ 2015-12-24 5:04 UTC (permalink / raw) To: musl On Wed, 23 Dec 2015 18:00:12 -0200 Alba Pompeo <albapompeo@gmail.com> wrote: > I also don't want to pollute my system with glibc. That's why I asked > if there was any plan to improve musl support of proprietary programs > like the ones I listed. > But as a last resort, I think Rich's method is the best so far, but > I'm a bit lost on the details since I'm not a libc expert. > I couldn't find a wiki page detailing Rich's method on Void or Alpine > (the 2 distros I know use musl). Is there a step-by-step for a novice > somewhere? There is also problem that musl wishes not to be fully glibc compat. Certain libc structs and public structs coming from glibc headers that are not required to be ABI same will be different on musl for performance or optimization reasons, and programs relying on them usually will not be happy. Simple programs probably still will work. I tried to hack into this area back in 0.9.x times (Jul2012). I even got userspace nvidia libraries being loaded by plain musl into `glxgears` and it did worked. Last time I revisited that was in Jan2015, and musl was greatly "improved" - applying same changes then trying to run the same `glxgears` resulted in plain segfault. From Jan2015 I was running X server in chroot, and completely moved to nouveau by Mar2015. Software that loads many-many shared objects, including modern GUI libs will BE unhappy. Just because when building with glibc result binaries are much polluted with glibcisms. My case was simpler. -- http://lynxlynx.tk/ Power electronics made simple Unix and simple KISS C code ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-24 5:04 ` Рысь @ 2015-12-24 5:16 ` Rich Felker 2015-12-24 10:40 ` Szabolcs Nagy 0 siblings, 1 reply; 19+ messages in thread From: Rich Felker @ 2015-12-24 5:16 UTC (permalink / raw) To: musl On Thu, Dec 24, 2015 at 12:04:42PM +0700, Рысь wrote: > On Wed, 23 Dec 2015 18:00:12 -0200 > Alba Pompeo <albapompeo@gmail.com> wrote: > > > I also don't want to pollute my system with glibc. That's why I asked > > if there was any plan to improve musl support of proprietary programs > > like the ones I listed. > > But as a last resort, I think Rich's method is the best so far, but > > I'm a bit lost on the details since I'm not a libc expert. > > I couldn't find a wiki page detailing Rich's method on Void or Alpine > > (the 2 distros I know use musl). Is there a step-by-step for a novice > > somewhere? > > There is also problem that musl wishes not to be fully glibc compat. > Certain libc structs and public structs coming from glibc headers that > are not required to be ABI same will be different on musl for > performance or optimization reasons, and programs relying on them > usually will not be happy. Simple programs probably still will work. There are no differences for performance or optimization reasons, unless you want to count [u]int_fastNN_t which are basically never used in public APIs anyway. Otherwise the only differences are that musl lacks the 32-bit-off_t structures on 32-bit archs (i.e. it can't match the _FILE_OFFSET_BITS=32 ABI on glibc, but it's not safe to use this ABI anymore anyway) and that musl does not copy the non-conforming, unsafe-because-it's-too-small glibc regoff_t on 64-bit archs (this only affects regexec). That's the situation for x86 and mainstream archs, at least. Some other archs have additional differences due to further brokenness in glibc (like IBM double-double on powerpc). Rich ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-24 5:16 ` Rich Felker @ 2015-12-24 10:40 ` Szabolcs Nagy 2015-12-27 3:54 ` Rich Felker 0 siblings, 1 reply; 19+ messages in thread From: Szabolcs Nagy @ 2015-12-24 10:40 UTC (permalink / raw) To: musl * Rich Felker <dalias@libc.org> [2015-12-24 00:16:25 -0500]: > On Thu, Dec 24, 2015 at 12:04:42PM +0700, ???????? wrote: > > There is also problem that musl wishes not to be fully glibc compat. > > Certain libc structs and public structs coming from glibc headers that > > are not required to be ABI same will be different on musl for > > performance or optimization reasons, and programs relying on them > > usually will not be happy. Simple programs probably still will work. > > There are no differences for performance or optimization reasons, > unless you want to count [u]int_fastNN_t which are basically never > used in public APIs anyway. Otherwise the only differences are that > musl lacks the 32-bit-off_t structures on 32-bit archs (i.e. it can't > match the _FILE_OFFSET_BITS=32 ABI on glibc, but it's not safe to use > this ABI anymore anyway) and that musl does not copy the > non-conforming, unsafe-because-it's-too-small glibc regoff_t on 64-bit > archs (this only affects regexec). > thread cancellation cleanup abi is different too (because glibc is broken for async-cancel) but nobody uses that so it should not be a problem the nvidia dso may segfault for many reasons, iirc the last time we identified that it uses stdio in a broken way, but there are numerous problems so a crash should not be a surprise. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-24 10:40 ` Szabolcs Nagy @ 2015-12-27 3:54 ` Rich Felker 0 siblings, 0 replies; 19+ messages in thread From: Rich Felker @ 2015-12-27 3:54 UTC (permalink / raw) To: musl On Thu, Dec 24, 2015 at 11:40:10AM +0100, Szabolcs Nagy wrote: > * Rich Felker <dalias@libc.org> [2015-12-24 00:16:25 -0500]: > > On Thu, Dec 24, 2015 at 12:04:42PM +0700, ???????? wrote: > > > There is also problem that musl wishes not to be fully glibc compat. > > > Certain libc structs and public structs coming from glibc headers that > > > are not required to be ABI same will be different on musl for > > > performance or optimization reasons, and programs relying on them > > > usually will not be happy. Simple programs probably still will work. > > > > There are no differences for performance or optimization reasons, > > unless you want to count [u]int_fastNN_t which are basically never > > used in public APIs anyway. Otherwise the only differences are that > > musl lacks the 32-bit-off_t structures on 32-bit archs (i.e. it can't > > match the _FILE_OFFSET_BITS=32 ABI on glibc, but it's not safe to use > > this ABI anymore anyway) and that musl does not copy the > > non-conforming, unsafe-because-it's-too-small glibc regoff_t on 64-bit > > archs (this only affects regexec). > > thread cancellation cleanup abi is different too > (because glibc is broken for async-cancel) > but nobody uses that so it should not be a problem Indeed, I forgot about that because it's not a types difference. I'd thought about possibly trying to support that too, but it looks hard and not worth the effort (or other costs). > the nvidia dso may segfault for many reasons, iirc > the last time we identified that it uses stdio in > a broken way, but there are numerous problems so > a crash should not be a surprise. Indeed, I think we found that it's assigning to stdout, which aside from being utter nonsense (stdout is not even specified to be an lvalue), happens to crash since musl's stdout is const and thus usually in read-only/relro memory. Rich ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-23 20:00 ` Alba Pompeo 2015-12-24 5:04 ` Рысь @ 2015-12-24 7:00 ` Isaac Dunham 2015-12-24 19:49 ` Isaac Dunham 1 sibling, 1 reply; 19+ messages in thread From: Isaac Dunham @ 2015-12-24 7:00 UTC (permalink / raw) To: musl On Wed, Dec 23, 2015 at 06:00:12PM -0200, Alba Pompeo wrote: > I also don't want to pollute my system with glibc. That's why I asked > if there was any plan to improve musl support of proprietary programs > like the ones I listed. I looked through the thread and saw no list of proprietary programs. (Is this undelivered mail? is google bouncing random emails?) > But as a last resort, I think Rich's method is the best so far, but > I'm a bit lost on the details since I'm not a libc expert. > I couldn't find a wiki page detailing Rich's method on Void or Alpine > (the 2 distros I know use musl). Is there a step-by-step for a novice > somewhere? I don't know of any step-by-step guide that covers what you're asking about, but I have done it before. The important things: * glibc uses paths configured in /etc/ld.so.conf, which these days usually just says "include /etc/ld.so.conf.d/*.conf". Those files, in turn, contain a newline-separated list of directories which are searched for libraries. musl uses /etc/ld-musl-$ARCH.path instead; this is a simple newline or colon separated list of directories. * with Debian's default configuration, the directories which glibc searches are {/usr/,/}lib/linux-$CPU-gnu, and /usr/local/lib. Delete /etc/ld.so.conf.d/libc.conf, and the library directory structure will have no conflicts with musl. * there are two possible approaches: - build a glibc chroot, drop a few links in /lib, put a few files in /etc, and you redirect glibc applications to the libraries in the chroot. - assemble a set of library packages, extract them, make sure there won't be conflicts, and copy it over into the root (so that you have both an Alpine install and a portion of a Debian install, with the same root) Only feasible with "multiarch-enabled" guest distros, meaning Debian and relatives. For the "use a chroot" approach, you will probably want to do something like this (assumes "guest" chroot in /opt/glibc-sys) touch /etc/ld.so.nohwcap sed -e 's|^/|/opt/glibc-sys/|' /opt/glibc-sys/etc/ld.so.conf.d/*.conf \ >/etc/ld.so.conf For the "parallel install" approach, I'd create a list of files that are both the glibc library set and the host, sort through them to figure out if they're needed/how to change them, and then do something like this (from the root of wherever you've extracted the libs to): rm ./etc/ld.so.conf.d/libc.conf find ./ | grep -v -x -F -f ../glibc-alpine-dupes | cpio -p / touch /etc/ld.so.nohwcap (This assumes that the list of duplicates is in the format: ./etc/passwd ...) HTH, Isaac Dunham ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-24 7:00 ` Isaac Dunham @ 2015-12-24 19:49 ` Isaac Dunham 2015-12-24 21:29 ` Alba Pompeo 0 siblings, 1 reply; 19+ messages in thread From: Isaac Dunham @ 2015-12-24 19:49 UTC (permalink / raw) To: musl On Wed, Dec 23, 2015 at 11:00:51PM -0800, Isaac Dunham wrote: > On Wed, Dec 23, 2015 at 06:00:12PM -0200, Alba Pompeo wrote: > > I also don't want to pollute my system with glibc. That's why I asked > > if there was any plan to improve musl support of proprietary programs > > like the ones I listed. > > I looked through the thread and saw no list of proprietary programs. > (Is this undelivered mail? is google bouncing random emails?) (Apparently didn't get successfully delivered from the list to me; thanks for sending a copy.) Looking at AMPL's linux32 demo, I get this list of missing functions: __divdi3 __fpu_control __isinf __isinfl __isnanl __strtod_internal fedisableexcept feenableexcept pthread_rwlockattr_setkind_np The first indicates that it may be necessary to add libgcc_s.so.1 to LD_PRELOAD. The rest are missing from musl for ABI compat. ampl and minos are "for GNU/Linux 2.2.5", so may use the 32-bit IO abi. __is* can be trivially implemented. __strtod_internal is a version of strtod with an extra int that's expected to be 0 (per LSB); no idea what that's for. HTH, Isaac Dunham ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-24 19:49 ` Isaac Dunham @ 2015-12-24 21:29 ` Alba Pompeo 0 siblings, 0 replies; 19+ messages in thread From: Alba Pompeo @ 2015-12-24 21:29 UTC (permalink / raw) To: musl Isaac, I just realized nobody on the mailing list received that copy I sent you. It was delivered to just 1 person by my mistake. Here's a copy to everyone. Here's a list of some programs I couldn't get to work - in alphabetical order and with links to those easily available (no registration required for free trial). AIMMS http://download.aimms.com/aimms/download/data/4.13/2.233/Aimms-4.13.2-233.x86_64.rpm AMPL http://ampl.com/dl/demo/ampl-demo-linux64.tar.gz MATLAB Siemens NX SPSS It was a colleague that recommended me musl and I immediately loved it after reading about its goals. But he forgot to tell me about these shortcomings, which he has too. We both have to dual-boot to use most proprietary software we need. Maybe we are doing something wrong? I both thanked my colleague to have introduced me to musl and cursed him for making my life harder :) But in general I'm pleased to use musl now. I hope the proprietary software I need works well. For now I'd like to focus on AMPL. I got it to run on a chroot as per my work colleague help, but Rich Felker's suggestions sounds much better. But I'm out of luck by being a novice user. Does anyone know of a guide for Void or Alpine (musl distributions) that explain it in a step-by-step? I couldn't find any. @Isaac If it makes things easier, CPLEX can be used instead of MINOS. Does that helps a bit? Ciao. On Thu, Dec 24, 2015 at 5:49 PM, Isaac Dunham <ibid.ag@gmail.com> wrote: > On Wed, Dec 23, 2015 at 11:00:51PM -0800, Isaac Dunham wrote: >> On Wed, Dec 23, 2015 at 06:00:12PM -0200, Alba Pompeo wrote: >> > I also don't want to pollute my system with glibc. That's why I asked >> > if there was any plan to improve musl support of proprietary programs >> > like the ones I listed. >> >> I looked through the thread and saw no list of proprietary programs. >> (Is this undelivered mail? is google bouncing random emails?) > > (Apparently didn't get successfully delivered from the list to me; thanks > for sending a copy.) > > Looking at AMPL's linux32 demo, I get this list of missing functions: > __divdi3 > __fpu_control > __isinf > __isinfl > __isnanl > __strtod_internal > fedisableexcept > feenableexcept > pthread_rwlockattr_setkind_np > > The first indicates that it may be necessary to add libgcc_s.so.1 to > LD_PRELOAD. > The rest are missing from musl for ABI compat. > ampl and minos are "for GNU/Linux 2.2.5", so may use the 32-bit IO abi. > __is* can be trivially implemented. > __strtod_internal is a version of strtod with an extra int that's expected > to be 0 (per LSB); no idea what that's for. > > HTH, > Isaac Dunham ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-23 18:51 ` Рысь 2015-12-23 20:00 ` Alba Pompeo @ 2015-12-24 5:12 ` Rich Felker 2015-12-24 7:20 ` Рысь 1 sibling, 1 reply; 19+ messages in thread From: Rich Felker @ 2015-12-24 5:12 UTC (permalink / raw) To: musl On Thu, Dec 24, 2015 at 01:51:35AM +0700, Рысь wrote: > On Wed, 23 Dec 2015 12:43:52 -0500 > Rich Felker <dalias@libc.org> wrote: > > > On Thu, Dec 24, 2015 at 12:22:05AM +0700, Рысь wrote: > > > On Wed, 23 Dec 2015 15:48:53 +0100 > > > Szabolcs Nagy <nsz@port70.net> wrote: > > > > > > > * Alba Pompeo <albapompeo@gmail.com> [2015-12-22 13:37:52 -0200]: > > > > > chroot is a little better than dual-boot, but still very > > > > > unfriendly for a day-to-day usage of many proprietary tools. > > > > > > > > > > > > > on x86, binaries linked against glibc can be made to work with > > > > musl. > > > > > > > > but isolating such software into a separate virtual environment > > > > is a good idea anyway and then it's easier to use glibc based > > > > userspace there. > > > > > > Well that's fine until you will not face something dynamic. A simple > > > example: some of my machines successfully runs LibreOffice 4 inside > > > Slackware 14 chroot. Problems start when user wants to save a > > > document to USB stick. This is a valid use case, but fails because > > > you end up with mounting USB stick twice. This requires wrappers. > > > And in *DE environments they will be lost under pressure of various > > > mount daemons or something like that. But at rest, it works > > > flawlessly. > > > > > > Maybe Alba Pompeo just faces an issue with wide filesystem tree that > > > needs to be inside chroot. > > > > I don't see why chroot is necessary at all. If you want a glibc > > environment for a single app you can put all the glibc stuff in its > > own library path and either invoke the binary manually using the glibc > > dynamic linker or have (a symlink to) the glibc dynamic linker in > > /lib. Then it can access the normal filesystem just fine. > > > > Containers (or just chroot) are of course preferable when you actually > > do want to isolate the program for trust/privilege purposes, but > > they're not a technical requirement for running foreign-libc binaries. > > And glibc will not pickup random musl linked shared objects from > standard paths (/lib:/usr/lib) from host? To be honest, I did not even > tried just because I do not want to pollute my systems with glibc. glibc's dynamic linker gets its library paths from ld.so.conf which is in $sysconfdir. If you build your own glibc you can set that to something other than /etc, or you can just be content with it living in /etc since musl does not use it. I'm not 100% sure it doesn't also have built-in default paths that aren't replaced by ld.so.conf, but if it does, those will be suppressed by building your own glibc with a different $prefix. Rich ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: musl & proprietary programs 2015-12-24 5:12 ` Rich Felker @ 2015-12-24 7:20 ` Рысь 0 siblings, 0 replies; 19+ messages in thread From: Рысь @ 2015-12-24 7:20 UTC (permalink / raw) To: musl On Thu, 24 Dec 2015 00:12:40 -0500 Rich Felker <dalias@libc.org> wrote: > On Thu, Dec 24, 2015 at 01:51:35AM +0700, Рысь wrote: > > On Wed, 23 Dec 2015 12:43:52 -0500 > > Rich Felker <dalias@libc.org> wrote: > > > > > On Thu, Dec 24, 2015 at 12:22:05AM +0700, Рысь wrote: > > > > On Wed, 23 Dec 2015 15:48:53 +0100 > > > > Szabolcs Nagy <nsz@port70.net> wrote: > > > > > > > > > * Alba Pompeo <albapompeo@gmail.com> [2015-12-22 13:37:52 > > > > > -0200]: > > > > > > chroot is a little better than dual-boot, but still very > > > > > > unfriendly for a day-to-day usage of many proprietary tools. > > > > > > > > > > > > > > > > on x86, binaries linked against glibc can be made to work with > > > > > musl. > > > > > > > > > > but isolating such software into a separate virtual > > > > > environment is a good idea anyway and then it's easier to use > > > > > glibc based userspace there. > > > > > > > > Well that's fine until you will not face something dynamic. A > > > > simple example: some of my machines successfully runs > > > > LibreOffice 4 inside Slackware 14 chroot. Problems start when > > > > user wants to save a document to USB stick. This is a valid use > > > > case, but fails because you end up with mounting USB stick > > > > twice. This requires wrappers. And in *DE environments they > > > > will be lost under pressure of various mount daemons or > > > > something like that. But at rest, it works flawlessly. > > > > > > > > Maybe Alba Pompeo just faces an issue with wide filesystem tree > > > > that needs to be inside chroot. > > > > > > I don't see why chroot is necessary at all. If you want a glibc > > > environment for a single app you can put all the glibc stuff in > > > its own library path and either invoke the binary manually using > > > the glibc dynamic linker or have (a symlink to) the glibc dynamic > > > linker in /lib. Then it can access the normal filesystem just > > > fine. > > > > > > Containers (or just chroot) are of course preferable when you > > > actually do want to isolate the program for trust/privilege > > > purposes, but they're not a technical requirement for running > > > foreign-libc binaries. > > > > And glibc will not pickup random musl linked shared objects from > > standard paths (/lib:/usr/lib) from host? To be honest, I did not > > even tried just because I do not want to pollute my systems with > > glibc. > > glibc's dynamic linker gets its library paths from ld.so.conf which is > in $sysconfdir. If you build your own glibc you can set that to > something other than /etc, or you can just be content with it living > in /etc since musl does not use it. I'm not 100% sure it doesn't also > have built-in default paths that aren't replaced by ld.so.conf, but if > it does, those will be suppressed by building your own glibc with a > different $prefix. > > Rich Just did experimented with fresh chroot. glibc indeed picks up libs from prefix where you'd put it and nowhere from if you said so in ld.so.conf. Unprefixed glibc (for example, taken from glibc system) requires /lib/ld*.so, /etc/ld.so.conf, /etc/ld.so.cache (generated by glibc's ldconfig, not necessary be put into /sbin) and that's counted by me as "being polluted with glibc" :-) But even if glibc works, there is still problem with embedded paths inside applications. Certain cases require hard debugging them with strace. Many can set RPATH into elf directly and you will end up hacking glibc not to load libs from RPATH. I do not remember exact details, but that temporary X server in chroot was the huge case of complex dlopen logic. So I use chroot just to avoid this complexity. -- http://lynxlynx.tk/ Power electronics made simple Unix and simple KISS C code ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2015-12-27 3:54 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-12-22 11:23 musl & proprietary programs Alba Pompeo 2015-12-22 11:27 ` Timo Teras 2015-12-22 15:25 ` Рысь 2015-12-22 15:37 ` Alba Pompeo 2015-12-23 14:48 ` Szabolcs Nagy 2015-12-23 16:01 ` u-uy74 2015-12-23 17:22 ` Рысь 2015-12-23 17:43 ` Rich Felker 2015-12-23 18:51 ` Рысь 2015-12-23 20:00 ` Alba Pompeo 2015-12-24 5:04 ` Рысь 2015-12-24 5:16 ` Rich Felker 2015-12-24 10:40 ` Szabolcs Nagy 2015-12-27 3:54 ` Rich Felker 2015-12-24 7:00 ` Isaac Dunham 2015-12-24 19:49 ` Isaac Dunham 2015-12-24 21:29 ` Alba Pompeo 2015-12-24 5:12 ` Rich Felker 2015-12-24 7:20 ` Рысь
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).