log
385 entries in 0.484s
trinque: mod6: this is expected; they're linked with glibc
a111: Logged on 2015-04-29 16:24 mod6: asciilifeform: I'm just trying to put together the monthy address; In one to three sentences cna you help me summarize what is going on with glibc/libnss?
asciilifeform: it's what's on s.mg an' dulap. but defo obsolete, it's a stone age glibc-based gentoo.
mircea_popescu: it seems strategically sound, "oh, i betcha they couldn't fuck gcc/glibc without gnat -- well, what if it can be denied!!!"
mircea_popescu: the issue isn't "use of gnat", the issue is, defanging of gcc/glibc/shitgnome ecosystem.
a111: Logged on 2019-03-01 15:09 spyked: re http://btcbase.org/log/2019-02-17#1897638 , specifically glibc is gonna go from my machines once I encuntooate them. it's not yet clear to me how this will impact e.g. apache, which calls dlopen for its loadable modules thing. google didn't turn out anything on the subj either.
spyked: re http://btcbase.org/log/2019-02-17#1897638 , specifically glibc is gonna go from my machines once I encuntooate them. it's not yet clear to me how this will impact e.g. apache, which calls dlopen for its loadable modules thing. google didn't turn out anything on the subj either. ☝︎☟︎
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: http://btcbase.org/log/2019-03-01#1899852 << so far we have signatures on glibc's death warrant from myself and asciilifeform iirc ☝︎
mircea_popescu: asciilifeform i'm aware, evolved not designed. nevertheless, the fundamental breakage here is that glibc is proposed as a "library" rather than a "kernel mod". not that these terms make any fucking sense anyway, but what the fuck am i gonna do.
mircea_popescu: terminology fails, mostly because terminology was made by morons and we're trying to discuss analysis in roman numerals here, but consider "glibc" would be a... well i guess a kernel mod the program links against as a library ?
mircea_popescu: ie, the fact that glibc doesn't come with sane memory allocator ~is a failure of glibc~.
asciilifeform: ( glibc & co. do not handle devices, impose memory organization scheme , etc )
mircea_popescu: then again this whiole discussion is moot, because step 1 towards that magical bios asm blob is a tmsr standards lib to replace glibc anyway.
trinque: http://btcbase.org/log/2019-02-17#1897638 << glibc has been banned from my own machines for some time. haven't missed it on desktop workstation, server, embedded. ☝︎
diana_coman considers eating treebark: ate it before, certainly better than eating glibc-barf
asciilifeform: diana_coman: the caveat is that i still dunhave a working cuntoo for all asciilifeform-operated irons; e.g. rk is still running barbaric old glibc gentoo
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)
mircea_popescu: this pretty much bans glibc, from my unexpert cursory look it dun seem fixable for sjlj.
asciilifeform: mircea_popescu: cuntoo is arguably a realtime test lab for 'what does removing glibc from ~errything~ cost'
mircea_popescu: can import glibc 3.x or w/e.
asciilifeform: re 'e', i can't picture what'd move anyone with two neurons to rub together to maintain a glibc, that'd be rather like starting a trb from prb 12 (or what is current one)
mircea_popescu: e. something else (among which possible e.1. someone reads and implements dwarf properly ; e.2. someone picks a glibc to grandfather and dedicates himself to cleaning and fixing.)
asciilifeform: ( e.g. 'bash bug', also drepper , also via glibc )
asciilifeform: glibc is simply poison.
mircea_popescu: yes, no glibc was in fact a preference, and we got it out, of trb, of eulora, etc. no argument there.
asciilifeform: this was a 2015 find. after which asciilifeform immediately proceeded to get glibc the hell out of trb.
asciilifeform: when uncovered that drepper (maintainer of glibc) deliberately broke static linkage globally
a111: Logged on 2015-04-29 16:28 mod6: so libnss is dynamically compiled and built/linked to glibc, and can not be avoided?
asciilifeform: was found that glibc actually prohibits static linkage.
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: glibc has 0 biz in tmsr proggy.
mircea_popescu: well, could also link against musl, ban glibc
mircea_popescu: zcx doesn't work, sjlj is broken and glibc is beyond salvation.
mircea_popescu: "curio cabinet" approx. but kunst is art, reminded me of teh whole thing, because guess what ? we all grew up with this idea foss/gcc/glibc/whatever "magic inside!!!"
mircea_popescu: "/* ??? Glibc has for a while now exported __register_frame_info and __deregister_frame_info. If we call __register_frame_info_bases from crtbegin (wherein it is declared weak), and this object does not get pulled from libgcc.a for other reasons, then the invocation of __deregister_frame_info will be resolved from glibc. Since the registration did not happen there, we'll die. Therefore, declare a new deregistration entry poi
asciilifeform: ( and already produced a self-contained, glibc-free retargetable gnat, works a++ for e.g. arm64 )
trinque: this would be expected if the bootstrap compiler requires a host glibc.
trinque: ave1: built with itself, but ever on a system without glibc?
trinque: asciilifeform: looks like ave1's script will bootstrap for you with a downloaded gnat, but the downloaded gnat wants to live on a glibc system. happily building on such.
mircea_popescu: it'll be so fucking splendid to link a bitcoin without glibc jaysus
a111: Logged on 2015-04-02 01:16 mircea_popescu: "/home/stas/bitcoin-v0_5_3_1/ourlibs/include/boost/asio/detail/impl/socket_ops.ipp:2900: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking"
asciilifeform: but localized the boojum to 'libnss' (which turned out to be component of glibc, and not removable)
asciilifeform: i cant speak for other folx, but asciilifeform's 'third eye' re rms opened on the day that he spat on that letter re glibc
asciilifeform: trinque: i was never able to build it under orginary glibc either.
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.
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
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
phf: posix mandates 6 x's, glibc 3 or more, etc. thanks bvt for catching it, though it seems like a solution is to roll own
asciilifeform: mkstemp : 'In glibc versions 2.06 and earlier, the file is created with permissions 0666, that is, read and write for all users. This old behavior may be a security risk... ...More generally, the POSIX specification of mkstemp() does not say anything about file modes...'
asciilifeform: they have option of ditching glibc, say. which hadnt then.
phf: ave1: this is trying to build on a glibc x86_64 debian 8.10
mircea_popescu: "According to POSIX.1-2001, the msg_controllen field of the msghdr structure should be typed as socklen_t, but glibc currently types it as size_t. " and other joys of the c world.
asciilifeform: sorta like glibc does with dns.
asciilifeform: in other noose, trad-gentoo's crossdev is completely rotten nao, tries to build glibc-2.27 (which is broken, as it won't build with any version of 'ld' i was able to find, full stop) EVEN WHEN YOU CROSSDEV ....linux-musl !!
Mocky: so in reading the logs I see that musl is a libc which is smaller and stricter than glibc. is there such a thing for c++ standard library or is it not needed?
phf: some libc's (specifically in glibc, musl, there's also a custom one in busybox. presumably cygwin/mingw comes with a glibc derivative), but that shouldn't be used directly. PeterL's patch is not needed on linux/freebsd/apple.
a111: Logged on 2018-07-15 15:45 trinque: musl will "break" where it refused to implement glibc feature-creep outside the posix libc standard. it's a stricter implementation.
a111: Logged on 2018-07-15 15:45 trinque: musl will "break" where it refused to implement glibc feature-creep outside the posix libc standard. it's a stricter implementation.
trinque: musl will "break" where it refused to implement glibc feature-creep outside the posix libc standard. it's a stricter implementation. ☟︎☟︎
asciilifeform: phf: only on a system where the systemwide crapola is traditional (glibc) and your musl item is a homedir-local build, a la rotor.
asciilifeform: ave1: this is The Right Thing, let glibc go to the bottom of the sea where it belongs.
diana_coman: asciilifeform, trinque's script is basically proto-cuntoo as far as I understand it; and it will result in a mulstronic system so why are we talking of a glibc box?
a111: Logged on 2018-06-21 12:34 asciilifeform: http://btcbase.org/log/2018-06-21#1827977 << 're-emerge' seems to imply systemwide ? you're more or less guaranteed a borked box, muslism has to be done either rotor-style (i.e. 100% user-local build of 1 proggy at a time) or systemwide ( trinque's cuntoo ), on account of the impossibility of cleanly linking glibc libs to musl proggy or vice versa
asciilifeform: diana_coman: you are aware that the only means of testing a musltronic build of your proggy + deps on a conventional (glibc) box, is the rotor method, yes
asciilifeform: the only way to muslate on a conventional (glibc) box, is via the rotor method.
asciilifeform: iirc i explained this in an earlier thread, but it is not possible to test selectively-musltronic e.g. mysql installed ~systemwide~ on a conventional glibc box
asciilifeform: generally speaking unless one or moar of your deps is weird in the 'emacs' way (i.e. does something obscene with glibc-specific pheatures) it's a straight mechanical job, like rotor.
asciilifeform: http://btcbase.org/log/2018-06-21#1827977 << 're-emerge' seems to imply systemwide ? you're more or less guaranteed a borked box, muslism has to be done either rotor-style (i.e. 100% user-local build of 1 proggy at a time) or systemwide ( trinque's cuntoo ), on account of the impossibility of cleanly linking glibc libs to musl proggy or vice versa ☝︎☟︎
asciilifeform: just about errything that doesn't abuse some glibc-specific knob, runs 100% under muslism ( e.g. trb, which was the first proggy i personally built for musl, back in the http://therealbitcoin.org/ml/btc-dev/2015-July/000133.html days )
phf: emacs does the same thing, except in order to do image dump it used some internal glibc (!!!) hack
spyked: ave1, printenv | grep CFLAGS/LDFLAGS both return nil so I'm okay on that front. but my glibc/ld are post-gcc-4.9, so your explanation about system headers being used sounds plausible.
ave1: spyked, http://btcbase.org/log/2018-05-23#1817663, no problem in fact the opposite. This helps in getting the cowwebs out of the build process (I've also tested on machines with gcc 7). The build process is picking up the glibc linux headers at a point where only musl headers should be used. This is usually caused by a system library being picked up in the build process. ☝︎
a111: Logged on 2018-05-16 04:19 ave1: it does not matter if the linux is glibc or musl, I tested also on a clean ubuntu arm64 image
ave1: it does not matter if the linux is glibc or musl, I tested also on a clean ubuntu arm64 image ☟︎
ave1: the static binaries, being static, run on all linuxes be it glibc or musl
ave1: Yes, 2.14 (this was to find out if I could make glibc produce smaller statically build outputs)
asciilifeform: stock glibc ?
ave1: It may also be something with the gmake on this machine, an earlier glibc also failed to build in parallel
ave1: I made a mistake on the earlier assertion, it works on glibc machines
asciilifeform: what 'won't work on glibc machines'
ave1: it's part of the cross compiler (under aarch64-linux-musl/aarch64-linux-musl/lib directory). The compilers assume it will live under /lib/ld.so, so that part won't work on glibc machines
ascii_lander: but on those you gotta be yourself statically linked (rather than trying to load glibc)
asciilifeform: but of actual dross. e.g. most of what glibc gloms on to every executable, never executes, these are bits you can flip with impunity
asciilifeform: ye olde 'These old versions of toolchain packages (binutils, gcc, glibc) are no longer officially supported and are not suitable for general use. Using these packages can result in build failures (and possible breakage) for many packages, and may leave your system vulnerable to known security exploits' nonsense.
spyked: anyway, I suspect all systems relying on shared libraries are stuck using the system-provided ld, regardless of the gcc version. if anything, because of the insane gcc defaults (glibc, dynamic symbols etc.) on newer distro versions.
mircea_popescu: dudes take glibc and fucking shove it.
asciilifeform: ( picture the elephantine drepper glibc in every bin )
a111: Logged on 2016-02-16 15:59 asciilifeform: 'The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack.'
spyked: http://btcbase.org/log/2017-11-20#1741206 <-- at some point, glib folks will decide that gcc < 5 isn't "modern enough" to build glibc, so they'll break compatibility. will, in the (now) tradition of introducing arbitrary changes. ☝︎
asciilifeform: the buildroot (aka 'rotor') thing is a dour wartime expedient, in case anyone forgot -- if we had a musltronic linux, or a bsd (i.e. non-glibc os) it would be unnecessary
asciilifeform attempts a build of traditional stator trb inside netbsd ( as rotor is unnecessary there, there is no drepper glibc )
asciilifeform: ( you can't dns from a statically linked glibc. but this does not bother me )
a111: 287 results for "glibc", http://btcbase.org/log-search?q=glibc
asciilifeform: !#s glibc
asciilifeform: or that glibc imports drepper's 0days for you
trinque: I dug a glibc trench for now while I fiddle with musl+X
asciilifeform: glibc is also not supported for trb.