log
469 entries in 0.566s
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
trinque: http://distfiles.gentoo.org/experimental/amd64/musl/ << yep, they purge them pretty aggressively
asciilifeform: ( and that no one had baked a musl stage3 that could be worked from that had <5 ? )
trinque: your traditional recipe is not on musl
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 ☝︎
diana_coman: in other lolz, #musl has a "feepbot"
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 ☝︎
asciilifeform: pretty sure shinohai already built eulora client on musl
trinque: probably there ought to be some euloran folks weighing in, maybe shinohai or someone tells us whether it can be built atop musl
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.
diana_coman: but I suspect it's simply one of those "you should prefer" a la http://ossasepia.com/2018/07/14/cutting-mysql-into-musl-shape/#selection-47.98-47.160
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: diana_coman: if it aint a seekrit: didja ever try building client on 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
mircea_popescu: asciilifeform getting an aarch64 musl sjlj going will be a fun task.
mircea_popescu: diana_coman looks like it's going the way of cuntoo-ada-musl, no glibc.
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 ?
asciilifeform: quite obv, any fix will have to fix musl.
mircea_popescu: well, could also link against musl, ban glibc
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
diana_coman: when I say "it built" above I mean specifically those versions: http://ave1.org/2018/building-gnat-on-musl-no-more-usrincludex86_64-linux-gnu/ and http://ave1.org/2018/building-gnat-on-musl-now-with-partial-and-parallel-build-support/ i.e. both static only and previous
ave1: O wait, I tried with: http://ave1.org/2018/building-gnat-on-musl-no-more-usrincludex86_64-linux-gnu/
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
asciilifeform: | GPL 2016 (20160515-49) (aarch64-linux-musl) GCC error: |
diana_coman: paging ave1 - do you have any idea re compiling GNAT with musl WITH sjlj? see thread above
a111: Logged on 2019-02-15 16:13 diana_coman: anyways, I'll try presently ave1's previous version i.e. http://ave1.org/2018/building-gnat-on-musl-now-with-partial-and-parallel-build-support/
diana_coman: anyways, I'll try presently ave1's previous version i.e. http://ave1.org/2018/building-gnat-on-musl-now-with-partial-and-parallel-build-support/ ☟︎
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 ☟︎
mod6: I'm not asking you to add my posbox foibles into your config. trb/ada/musl that I want to test on there doesn't care what kernel modules are loaded.
asciilifeform: the only hit is x86_64-linux-musl/share/info/mpc.info -- a readme
diana_coman: ave1 or anyone else more experienced in rebuilding ave1's gnat with a previous incarnation of same: I'm trying to build using the scripts in ada-musl-cross-2018-09-24.tgz on a machine that has as only existing and perfectly working !) gnat a previous ave1 gnat version; I ran as the readme says simply ./build-ada.sh absolute_path_to_dir but the whole thing fails because it doesn't find some libs such as libgmp.la; a closer look at the outpu
bvt: musl-cross-make
bvt: built myself, based on ave1s patches and musl-cross-make (https://github.com/richfelker/musl-cross-make/ , i had some experience with it so did the work rather quickly).
asciilifeform: maybe musl implements some functionality is a way unexpected << where didja get a gcc5istic gnat built on musl, bvt ??
trinque: x11 runs fine on musl
mircea_popescu: trinque "it's a test of musl" in the sense that if something breaks it'll likely be that, not reasonable to expect that because you took out whatever solitaire version gets bundled with gentoobuntu then therefore your build crashes.
trinque: yes, snapshot-and-fork of a musl-gentoo, but particularly that the snapshotting produces a genesis.vpatch
diana_coman: aha; well, mine is stock gentoo rather than musl so yes
a111: Logged on 2019-02-03 04:03 trinque: GNU bash, version 4.4.12(1)-release (x86_64-gentoo-linux-musl)
a111: Logged on 2019-02-03 00:35 trinque: ave1: is it your experience that your gcc+gnat builds on musl? builds for musl, yes, but on?
ave1: trinque, http://btcbase.org/log/2019-02-03#1891961, I've build it with itself (i.e. musl). But the ultimate start has always been the gcc version from AdaCore. I could not get it to work with an FSF start. ☝︎
trinque: GNU bash, version 4.4.12(1)-release (x86_64-gentoo-linux-musl) ☟︎
trinque: ave1: is it your experience that your gcc+gnat builds on musl? builds for musl, yes, but on? ☟︎
shinohai: Not bad, just noticed last nite ave1's site back up so in process of building musl gnat today then on to revisiting ffa stuffs
asciilifeform: given as it comes already with sane gcc and musl
mod6: I'm currently building out a Cuntoo (have had a minor issue with my kernel not booting correctly, but will work on that soon), and will use that + ave1's musl to build the keccak v tooling, and then TRB. Which will also go into the upcoming changes to the HOWTO Guide.
asciilifeform: ( 'rotor' & descendants, on musl )
trinque: asciilifeform: I failed repeatedly to build chrome on musl, said "fuck it", dustbinned.
trinque: asciilifeform: I've built ff on musl with various rando's patches, have one running currently
trinque: asciilifeform: we had a thread on the stepping down before, jumping directly to 4.9.4 does not work on musl. not a clue why.
asciilifeform: http://btcbase.org/log/2018-11-24#1874369 << is this also true in musl , trinque ? i haven't looked closely yet ☝︎
trinque: I'll need to read up on how DNS resolution works in musl to recommend something strongly, but might be as simple as having it read a second hosts file. I don't know of any support for including one hosts file in another in either musl or glibc.
deedbot: http://bvt-trace.net/2018/10/linux-portability-part-2-exploring-musl-ifdefs-or-define-pdp_endian-3412/ << bvt's backtrace - Linux Portability, Part 2: Exploring musl #ifdefs, or #define PDP_ENDIAN 3412
deedbot: http://bvt-trace.net/2018/10/linux-portability-part-1-exploring-musl-architecture-specific-headers/ << bvt's backtrace - Linux Portability, Part 1: Exploring musl Architecture-Specific Headers
billymg: is this the right place to start reading to get gnat installed? http://ave1.org/2018/building-gnat-on-musl-no-more-usrincludex86_64-linux-gnu/
bvt: http://bvt-trace.net/2018/10/linux-portability-part-2-exploring-musl-ifdefs-or-define-pdp_endian-3412/
bvt: hi, i have made some exploration of linux syscall interface (using musl) http://bvt-trace.net/2018/10/linux-portability-part-1-exploring-musl-architecture-specific-headers/
bvt: well, http://git.musl-libc.org/cgit/musl/tree/src/network/connect.c -- the structure is the same; digging is rather easy, if you don't look into glibc
bvt: the thing is, structure definitions and all sort of flag numbers appear in the libc via magic. having all this things in ada is possible, and would involve exactly same work that e.g. musl people are doing today
bvt: but so far it's not clear what the subset should be, what to do about C structures (with problems like e.g. https://www.openwall.com/lists/musl/2017/01/25/1)
phf: well, it's also a reason why bug wasn't caught in development. a sequence of wtfs: linux man page says mktemp should be 3 or more X's, so project builds on a non-musl build. meanwhile POSIX mandates there to be exactly 6 X's, so a musl build fails to produce a random string, returning instead a blank one, which is when gnat decides to not only generate a temp file but also do cleanup.
bvt: 3. Musl calculates a simple hash over current time, address of variable on stack, and address of template to generate the random characters for mk*temp family of functions: http://git.musl-libc.org/cgit/musl/tree/src/temp/__randname.c#n6
phf: asciilifeform: to be fair musl's version is naive, it generates/stats in a loop until there's no collision, but theoretically you can still get a race condition. glibc i believe does all kinds of smart tricks to ensure that doesn't happen, but it's all magic
bvt: Reapplied ave1's patches over gnat17, and musl-cross-make (https://github.com/richfelker/musl-cross-make/)
bvt: musl wants 6 template chars: http://git.musl-libc.org/cgit/musl/tree/src/temp/mktemp.c#n13
asciilifeform: and the orig 'rotor', i baked for tbf, and from it we have the musl thing, etc
deedbot: http://ave1.org/2018/building-gnat-on-musl-no-more-usrincludex86_64-linux-gnu/ << ave1 - Building GNAT on MUSL, no more /usr/include/x86_64-linux-gnu
trinque: quick update on cuntoo before I depart. the fully machine-driven transformation from snapshotted gentoo to cuntoo genesis.vpatch works, and successfully rebuilt itself whole. I've also got the classical gentoo repo acting as a subordinate repository, such that porting ebuilds will be extremely easy (i.e. gentoo repo is now an overlay, just like musl overlay, which can be used or not as decreed by operator,
a111: Logged on 2018-09-22 18:46 phf: asciilifeform: that i can see, but i'm not sure why it's picking up system wide includes. there's an isystem there that points to correct musl include tree, that has the sys/types.h file in it