tmsr - Search: musl

ossabot: Logged on 2020-03-06 14:29:53 jfw: mp_en_viaje: http://logs.ossasepia.com/log/trilema/2020-03-05#1958950 - still worked, though that was on a musl gawk, perhaps it's special in a sufficiently different way. I don't have a drepper box around with that much disk atm. I'll believe it once blew up in some environment though.

jfw: mp_en_viaje: http://logs.ossasepia.com/log/trilema/2020-03-05#1958950 - still worked, though that was on a musl gawk, perhaps it's special in a sufficiently different way. I don't have a drepper box around with that much disk atm. I'll believe it once blew up in some environment though.

mircea_popescu: in the end it turns out, forking musl is unavoidable on very deep, far reaching, fundamental grounds.

mircea_popescu: illiterate users of spellkits for their own name seem to me less desirable than literate people, so whathevers. i guess the practical difference between musl and say python is actually nil, and if you want to use it you'll have to fork and maintain it.

jfw: http://archive.is/ghjcb << my reply to musl, couldn't resist rubbing in a bit more salt.

jfw: Latest from the musl thread, from the main guy Felker: https://www.openwall.com/lists/musl/2020/02/19/4 ( http://archive.is/maiqg ). In brief - perhaps I'm underinformed on specifics but in general full unicodeism has been their goal from the start

jfw: funny how mircea_popescu probably speaks more languages than half the musl-using population combined...

ossabot: Logged on 2020-02-18 15:58:41 ossabot: Logged on 2020-02-04 22:40:07 mircea_popescu: jfw, re the whole musl & locales issue, it might be an idea to signal to them, "look, we use musl, and we don't think this is a good idea". irrespective of whether it does anything, at least that way they can't say they didn't realise "unanimity" is hallucinated etc.

ossabot: Logged on 2020-02-04 22:40:07 mircea_popescu: jfw, re the whole musl & locales issue, it might be an idea to signal to them, "look, we use musl, and we don't think this is a good idea". irrespective of whether it does anything, at least that way they can't say they didn't realise "unanimity" is hallucinated etc.

ossabot: Logged on 2020-02-17 18:32:47 dorion: I'll let him show and tell, his patch removes the whole rotor orchestra since Gales is musl static anyway.

dorion: I'll let him show and tell, his patch removes the whole rotor orchestra since Gales is musl static anyway.

jfw: mircea_popescu: good idea. ugh, 'Locale support overhaul' and 'resolver support for non-ASCII domains' already slated for April

mircea_popescu: jfw, re the whole musl & locales issue, it might be an idea to signal to them, "look, we use musl, and we don't think this is a good idea". irrespective of whether it does anything, at least that way they can't say they didn't realise "unanimity" is hallucinated etc.

mircea_popescu: from what I understand, it's not possible to compile Emacs using Musl << bwahahaha what the fuck

jfw: The split existed historically in that they developed as separate projects; gcc works with multiple c libraries as musl works with multiple compilers. Perhaps mircea_popescu is inquiring into a deeper question of whether it's right to maintain the split (presently - I've no idea)

ossabot: Logged on 2019-11-27 15:33:20 jfw: http://logs.ossasepia.com/log/trilema/2019-11-27#1953705 - Could be. There's a decision that will be needed between glibc, dynamic musl, static musl, some mixture or framework with multiple options, or what. This is a part of the server vs. graphics split that bvt mentioned, or work vs. play if that's a fair characterization of

dorion_road: mircea_popescu gcc refers to c compiler, ave1 said he's working on a genesis based on version 4.9.4. By c library I mean the choice essentially between glibc and musl and dynamic and static linking, e.g. http://logs.ossasepia.com/log/trilema/2019-11-27#1953721

diana_coman: jfw: ave1 has GNAT running on musl, no need for the frozen Adacore version really.

jfw: Besides proprietary GPU drivers there are other "traditional Linux" things not likely to run on musl with any amount of futzing, such as compiled non-static binaries (proprietary apps, the Adacore GNAT distribution) and "enterprisey" thinks like authentication plugins; I can't speak to whether we should care about these.

jfw: My view of musl is that it's substantially smaller and cleaner than glibc, but still has a substantial rate of bugfixes mixed in with feature additions. My sense is that many of these are in the area of threading / concurrency, for which they wrote a new implementation of the userspace part, and also an area I'm less familiar with though wouldn't mind improving on.

ossabot: Logged on 2019-11-27 15:01:28 dorion_road: jfw I know you've spent a good deal of time with musl in the process of getting Gales statically linked , do you think owning the c library is a good fit for you ?

jfw: http://logs.ossasepia.com/log/trilema/2019-11-27#1953705 - Could be. There's a decision that will be needed between glibc, dynamic musl, static musl, some mixture or framework with multiple options, or what. This is a part of the server vs. graphics split that bvt mentioned, or work vs. play if that's a fair characterization of

ossabot: Logged on 2019-11-12 16:57:31 jfw: It's a Linux distro I put together, in a couple stages, based on gcc 4.7, musl, busybox userland, exclusively static linking

dorion_road: jfw I know you've spent a good deal of time with musl in the process of getting Gales statically linked , do you think owning the c library is a good fit for you ?

dorion_road: http://logs.ossasepia.com/log/trilema/2019-11-25#1953501 << well, the gcc, busybox, musl static, et cetera work you've done with Gales are all of interest to the conversation and decision making from my view.

jfw: I've built a basic X stack (no 3d accel) on dynamic-linked musl, the biggest uncertainty to me there is whether it'll work static since it's module-oriented

jfw: It's a Linux distro I put together, in a couple stages, based on gcc 4.7, musl, busybox userland, exclusively static linking

BingoBoingo: trinque: If I do get a Cuntoo running this weekend, you can expect me to submit Cuntoo-ified versions of my desktop work tools at the speed I port them. Everything I depend on seems to have already been ported to musl based linux distributions. I can't promise doing this fast, but it can be something that would help make a noob-cuntoo image down the line.

snsabot: Logged on 2019-08-09 17:04:22 bvt: asciilifeform: fished out some info re aws: http://p.bvulpes.com/pastes/koCFa/?raw=true (small patch for musl compat) and http://p.bvulpes.com/pastes/avKyY/?raw=true (build instructions) seem to be it

bvt: asciilifeform: fished out some info re aws: http://p.bvulpes.com/pastes/koCFa/?raw=true (small patch for musl compat) and http://p.bvulpes.com/pastes/avKyY/?raw=true (build instructions) seem to be it

a111: Logged on 2019-07-17 13:22 asciilifeform: however it only provides 'uclibc' (and not musl, as prev. noted.)

asciilifeform: the unsolved puzzlers, for that experiment, are, in order of pain : 1) buildroot w/ musl 2) 100% gcc-4.7 process 3) nic emulation . ☝︎

a111: Logged on 2019-07-17 12:16 asciilifeform: problem comes if you want to run non-contemporary proggies on it ( musl, gnat 4.9.x, etc . ) linus permitted abi to change.

mp_en_viaje: http://btcbase.org/log/2019-07-17#1922914 << the schmucks are pretty shameless, it is true, but perhaps not many notches above trivial to reconstruct musl atop a proper (ie, without Peter Korsgaard &rest of retards) ☝︎

asciilifeform: problem comes if you want to run non-contemporary proggies on it ( musl, gnat 4.9.x, etc . ) linus permitted abi to change. ☟︎

asciilifeform: this wouldn't even be interesting ('hey use pre-castration snapshot') except that this snip pre-dates addition of musl to buildroot.

mp_en_viaje: diana_coman, but basically, it's running the same thing from 2018 ; and the reason it doesnt move is that a) we couldn't give less of a shit about ebuilds while b) we can't easily change the pile of dependencies to live with musl and so yet haven't.

mod6: I hope I'm not doing anything redundant really. The Makefiles itself take care of the compilation of Boost/BDB/OpenSSL. The one thing that I still need from the rotor.tar.gz is 'openssl-004-musl-termios.patch'

mod6: asciilifeform: I changed all of the CC, CXX, LD to point at all of the binaries located in the tarball I extracted from the build of Ave1's GNAT, like this one: /opt/20180924/x86_64-linux-musl-native/bin/gcc

mp_en_viaje: asciilifeform, in general, i do not see there's any need for having a musl gcc in the first place.

asciilifeform: mp_en_viaje: re 'gcc ladder', the orig boojum was the 'catch-22' where a musl gcc can only be built w/ another musl gcc , and the only working specimen trinque was able to find in the wild, was a gcc6

asciilifeform: http://btcbase.org/log/2019-04-23#1909530 << iirc the orig problem was that the published musl gentoo starter culture trinque began working from, was built on gcc6 , which won't build 4.x (and therefore full replication involves stepping 6 -> 5 -> 4.9 ) ☝︎

a111: Logged on 2019-04-22 16:19 trinque: his gcc does not build upon musl, so I have not. prodded him a few times about getting his to run on a musl box.

trinque: his gcc does not build upon musl, so I have not. prodded him a few times about getting his to run on a musl box. ☟︎

trinque: anyhow, my project here was to take a snapshot of a working gentoo musl, i.e. a snapshot of the work of others. I intentally kept myself out of the chain of custody of all deps.

asciilifeform: i was able to bake a musl 'busybox' linux for pogo in '15, but admittedly this was not a gentoo

asciilifeform: ( and that no one had baked a musl stage3 that could be worked from that had <5 ? )

BingoBoingo: OriansJ: Well right now we have some people working on flensing a minimal linux from Gentoo-MUSL and other people building utilities in ADA

bvt: something like i.e. /cuntoo/portage/profiles/root/cuntoo/build/usr/portage/profiles/features/musl/use.mask

a111: Logged on 2015-07-05 08:22 mircea_popescu: heh check it out, mark karpeles idling in #musl.

a111: Logged on 2015-07-05 15:04 asciilifeform: 'Topic for #musl is: http://www.musl-libc.org | Ask questions; treat others with respect; stop off-topic discussions for musl questions; do not publish logs; no sexism, homophobia, or other forms of asshattery.'

diana_coman: I was curious re activity @ musl so I joined the channel: the topic is same as http://btcbase.org/log/2015-07-05#1188244 ☝︎

a111: Logged on 2019-02-17 16:07 mircea_popescu: c. ada-?-musl-static is the standard, either zcx or sjlj is acceptable (mostly based on what threading philosophy one embraces), with an obvious preference for zcx if one doesn't thread.

a111: Logged on 2019-02-17 15:49 asciilifeform: mircea_popescu: it already worx , afaik, on musl, ave1's gnat shits out strictly musl-static linkage.

bvt: http://btcbase.org/log/2019-02-17#1897636 << as long as i need userspace C code to run, I'll be happy to use musl. it's not bugs-free, but its bugs have very different nature than glibc's. i see no reason for keeping glibc on non-toiletboxes. ☝︎

phf: http://btcbase.org/log/2019-02-17#1897638 << i've been building everything using ave1's gcc/gnat which is musl based. i don't see any reason to keep glibc ☝︎

trinque: probably there ought to be some euloran folks weighing in, maybe shinohai or someone tells us whether it can be built atop musl

lobbes: good day, #t. Quick update on what I've been doing lately: I've been on a bridge-to-cuntoo quest. Firstly, I spent the last week or so successfully getting a hand-rolled classic Gentoo installed on my lappy; complete with alf's classic crapolade masks, functioning networking, gcc-musl, ave1's gnat, and diana_coman's v setup (tested and working splendidly, I will add).

mircea_popescu: ada-musl will have to get its own backend, even if it's mpi-style confiscation.

trinque: https://gitweb.gentoo.org/proj/musl.git/log/app-editors/emacs?qt=grep&q=emacs << looks like youngest they had was 24.5, have sinced removed patches from the overlay claiming mainline works

trinque: asciilifeform: iirc last thing I built was in portage proper, built atop musl. this was probably a late and fungal version number

a111: Logged on 2019-02-17 16:21 asciilifeform: ( e.g. asciilifeform was quite surprised when found that trb and ALL deps built cleanly & functioned on static musl )

asciilifeform: ( e.g. asciilifeform was quite surprised when found that trb and ALL deps built cleanly & functioned on static musl ) ☟︎

asciilifeform: mircea_popescu: fix of sjlj on arm64 is actually moar urgent than arm-cuntoo, cuz sanely build ( static-musl ) ~will~ run on glibcistic linux

diana_coman: re glibc: until now I saw it as tolerated until full tmsr version (whatever that might be, i.e. owned glibc version or musl or whatever)

asciilifeform: i dun see where drepperism wins in ~any~ version, vs. the ab initio and 10x moar compact musl.

mircea_popescu: d. ada-zcx-musl-static is the standard for non-threaded programs, we don't standardize threading.

mircea_popescu: c. ada-?-musl-static is the standard, either zcx or sjlj is acceptable (mostly based on what threading philosophy one embraces), with an obvious preference for zcx if one doesn't thread. ☟︎☟︎

mircea_popescu: b. ada-sjlj-musl-static is the standard, and we simply don't sign or use anything that doesn't live up to this.

mircea_popescu: a. we make no standard, every man for his own, but : a.1. ada is the preferred language ; a.2. musl is the preferred standards provider ; a.3. zcx is the preferred exception mechanism ; a.4. static is the preferred build mode. this should come with a design process for candidates evaluation for standardization.

asciilifeform: item is ~10x the mass of musl, and fulla 'surprises' that erry time turned out to be architecturally baked in.

mircea_popescu: asciilifeform yes. but to my knowledge to date musl was a preference rather than a standard. we never said "no more glibc linking" as we said eg http://btcbase.org/log/2018-09-19#1851879 ☝︎

asciilifeform: mircea_popescu: it already worx , afaik, on musl, ave1's gnat shits out strictly musl-static linkage. ☟︎

asciilifeform: ( half the reason why asciilifeform dug out musl, is that it's compact enuff to be fixable, at least in principle )

mircea_popescu: so is basically the idea what we want is to get sjlj to work on musl for ada proggies ? or what ?

bvt: they disabled weak symbols for c++/fortran components, http://port70.net/~nsz/musl/gcc-5.3.0/0004-gthr.patch

bvt: i still have no solution for this, afaik musl authors solved the problem for fortran and c++, but gnat seems to lack equivalent knob

a111: Logged on 2019-02-15 16:12 diana_coman: hm, full replica might require I upload somewhere the tarballs too since at least 1 link was broken ; anyways, it's with http://ave1.org/2018/building-gnat-on-musl-now-always-static/ + taken out the download script for ada2016 because broken link + added GCC_CONFFLAGS="--enable-sjlj-exceptions" to extraconfig.sh ; set path to point to existing and working adacore 2016 gnat + put all tarballs in their place