Results 1 ... 250 found in all logged channels for 'glibc' | →
(pest) dulapbot: Logged on 2024-07-01 20:06:58 asciilifeform: glibc-only (claimed, 0 usable detail in the piece, unsurprise)
(pest) asciilifeform: glibc-only (claimed, 0 usable detail in the piece, unsurprise)
(pest) hapax: right now if you wanna do posix-like on dos it's either glibc or various incompatible libcs bundled with c compilers (with incompatible versions of c)
(pest) asciilifeform: 'All glibc versions from at least September 1992 (glibc 1.04) to the current release ... affected' etc
(pest) dulapbot: (asciilifeform) 2020-07-26 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2020-07-26#1017239 << there's ~6 years of history here ( and that's simply from asciilifeform's pov, other folx struggled longer. ) in '15, found that glibc project has been operated by wreckers, for years. and deliberately sneaks dyn. loads into 'static' builds. after some work, found cure -- to throw glibc the fuck out.
(pest) dulapbot: (asciilifeform) 2020-04-03 shinohai: Latest glibc "update" broke ~75% of coins.
(pest) asciilifeform: ( musl being a sane replacement for glibc where drepper's vandlism isn't present and static linking worx 100% )
(pest) asciilifeform: PeterL: see logs. nominally 'for seekoority' but factually forced by drepper & his fellow nsa assets to help maintain vuln footprint
(pest) asciilifeform: PeterL: PeterL: e.g. 'libc.so.6: version `GLIBC_2.14' not found' and similar idiocy
(asciilifeform) shinohai: (if on a glibc system)
(pest) billymg: `uname -m`: x86_64. glibc gentoo host
(pest) signpost[asciilifeform]: shinohai: sounds about right. elfutils (which contains libelf) wanted a bunch of other non-posix glibc funcs, which brought in argp-standalone, musl-fts, musl-obstack
(asciilifeform) asciilifeform: it's fucking insulting to one's intelligence to see '200 byte hex monitor' 'but also glibc, gcc, guile, but Doesn't Count Because Reasons'
(asciilifeform) bitbot: (therealbitcoin) 2020-07-08 jurov: For the record, I should mention that rotor needs glibc <2.28 on build system because it moved some include files which break the bootstraping of m4.
(asciilifeform) billymg: asciilifeform: not on newer ones with glibc > 2.28
(pest) billymg: i probably should've made this a glibc system
(pest) asciilifeform: shinohai: fwiw asciilifeform currently only has traditional glibc boxen
(pest) shinohai[asciilifeform|billymg] hangs head because using glibc on daily driver atm ....
(pest) billymg: whaack: do you also have gnat on your system? is it musl-based or glibc?
(pest) billymg: if anyone can help me out i have three main questions right now (to sanity check that i'm even attempting to do the right things) -- 1) should the 2016 gnat bin work on a musl system? 2) are ave1's instructions meant to be followed on a musl machine or glibc mac
(pest) billymg: made some progress with building the musl gnat. i followed ave1's instructions and ran the `./build-ada.sh </install/directory> > build.output 2>&1` successfully on my other, glibc based, machine
(asciilifeform) billymg: there are patches available for m4 to get around the >=glibc 2.28 problem, one was even included in my stock system's m4 ebuild
(asciilifeform) dulapbot: (therealbitcoin) 2020-07-08 jurov: For the record, I should mention that rotor needs glibc <2.28 on build system because it moved some include files which break the bootstraping of m4.
(asciilifeform) asciilifeform: billymg: unless you went to special lengths to get a musltronic gentoo, yea it's glibc
(asciilifeform) billymg: signpost, asciilifeform: i believe my system is glibc currently rather than musl
(asciilifeform) asciilifeform: verisimilitude: 0 to do with my 'fossilized gentoo' at all, mine is a more modest effort to simply preserve the 2016 era glibc-based traditional gentoo and various packages.
(asciilifeform) snsabot: Logged on 2020-12-16 12:11:49 asciilifeform: cgra: neato. (btw, in case wasn't obvious, the gnat used by asciilifeform for ffa work has been glibc-free since ch11)
(asciilifeform) asciilifeform: cgra: neato. (btw, in case wasn't obvious, the gnat used by asciilifeform for ffa work has been glibc-free since ch11)
(asciilifeform) cgra: the course i'm now attending for my sane computing curriculum, is binary auditability. atm i'm carving out the glibc bloat and trinque's musl bootstrap seemed like a suitable ingredient. i just finished building it and came to report the results so far
(asciilifeform) trinque: I have not had much luck bootstrapping from a glibc system
(asciilifeform) trinque: asciilifeform: btw your dulap image is glibc
(asciilifeform) asciilifeform: Aerthean: building a musl-based gcc toolchain is not so hard; the harder thing is getting 100% of proggies to actually build in it (for some, trivial, for others -- e.g. emacs -- yet-unsolved afaik , some of'em use glibcisms specifically )
(asciilifeform) asciilifeform: Aerthean: actually this gentoo still based on traditional glibc. static linking in it still has to be done by building a separate gcc + toolchain, or using ave1's gnat , or similar.
(asciilifeform) snsabot: Logged on 2020-08-08 15:02:45 asciilifeform: there in fact is commercial soft for linux, that is normally distributed as static (or quasi-static, when glibc victims) binaries.
(asciilifeform) asciilifeform: that being said, the fungus is in his brain nao, and you can safely bet money that eventually 'oops we broke it, but dunworry, get latest glibc'.
(asciilifeform) asciilifeform: there in fact is commercial soft for linux, that is normally distributed as static (or quasi-static, when glibc victims) binaries.
(asciilifeform) asciilifeform: drepper's sabotage of static linking took place in glibc and nowhere else.
(asciilifeform) asciilifeform: whether ye olde pieceofshit glibc, or the moar compact musl, ultimately all work same way.
(asciilifeform) asciilifeform: for yet-further ref -- glibcistic gnat rts weighs ~1MB; musltronic -- 300k; a theoretically minimal (per ffa) one would weight coupla kB.
(ossasepia) jfw: whaack, http://trinque.org/2019/12/29/a-republican-os-part-2/ might be a start for glibc vs. musl which is a somewhat distinct question from dynamic linking
(ossasepia) jfw: well for instance, I'm sure it can be got to build on CentOS, but that would mean it ends up with glibc and probably some degree of dynamic linking, which for a certain view of what a bitcoin node is, won't count as sane
(asciilifeform) asciilifeform: i did this for trb in '15 ; ave1 for gnat in '18; and trinque is taking the subj to logical conclusion and baking a usable 100% glibc-free linuxism
(asciilifeform) asciilifeform: i.e. to replace it with compact and ~100% compat. libc 'musl'. (1st requires building gcc, bintools, etc. ~under~ musl, because gcc that has been contaminated with glibc can ~only~ build w/ glibc.. )
(asciilifeform) asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2020-07-26#1017239 << there's ~6 years of history here ( and that's simply from asciilifeform's pov, other folx struggled longer. ) in '15, found that glibc project has been operated by wreckers, for years. and deliberately sneaks dyn. loads into 'static' builds. after some work, found cure -- to throw glibc the fuck out.
(therealbitcoin) jurov: For the record, I should mention that rotor needs glibc <2.28 on build system because it moved some include files which break the bootstraping of m4.
(asciilifeform) shinohai: Latest glibc "update" broke ~75% of coins.
(ossasepia) jfw: BIND, an old and ill-reputed monolithic DNS server, includes side utilities "host" and "nslookup". Glibc includes "getent hosts". I tend to use djbdns which includes "dnsip" and similar, though isn't widely installed by default.
(ossasepia) jfw: the LFS handbook might make a good companion reference too, as I recall it went into greater depth on some explanations, though many of the steps involving glibc / dynamic linking aren't needed.
(trilema) 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
(trilema) 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
(trilema) 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.
(trilema) 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
(trilema) ossabot: Logged on 2019-11-12 17:07:58 jfw: I expect that'd be quite difficult, its libGL is a glibc-based .so
(asciilifeform) shinohai: nb ... glibc gets more liquidy every passing day anyways.
(asciilifeform) shinohai: In other interesting gentoo stuff, one of the girls acquired new lappy and I installed gentoo on it. If you try and build trb on it, does not work - glibc causes buildroot step to fail with "error "Please port gnulib fseeko.c to your platform!"
(trilema) jfw: I expect that'd be quite difficult, its libGL is a glibc-based .so
(trilema) asciilifeform: in the end asciilifeform cut out glibc entirely, and never again gave a shit re whether it is fixed or not.
(trilema) asciilifeform: summary in log, iirc was : asciilifeform wrote to rms re the 'libnss' garbage preventing static linking of glibc. rms 0 reply. but when mircea_popescu wrote, rms answered w/ jwzisms.
(trilema) snsabot: Logged on 2019-06-02 06:48:29 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?
(trilema) asciilifeform: mircea_popescu: re glibc -- iirc subj of inquiry was re the 'nss' thing, which i found to be the sublib that drags in dynamicism, dns, etc
(trilema) asciilifeform: oh hey mircea_popescu do you still have that letter where he took a shit on asciilifeform's complaint re glibc ?
(trilema) asciilifeform: spyked: this here ~is~ a glibcistic system, frozen in amber circa 2011 or so
(trilema) spyked used perf with some limited degree of success in the past. could measure cache/tlb/branch predictor misses with it. but admittedly, never tried it on non-glibc systems.
(trilema) asciilifeform: 'Makefile:542: *** No gnu/libc-version.h found, please install glibc-dev[el]/glibc-static. Stop.'
(trilema) spyked: ugh, dunno why it asks for glibc. the only specific item it might require would be kernel knob for counters or whatever.
(trilema) trinque: learn about runit or hell glibc
(trilema) trinque: mod6: this is expected; they're linked with glibc
(trilema) 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?
(trilema) asciilifeform: ave1's musltronic gnat does run on each, and so do the musltronic bins it births. however the system utils are still glibcistic.
(trilema) asciilifeform: it's what's on s.mg an' dulap. but defo obsolete, it's a stone age glibc-based gentoo.
(trilema) mircea_popescu: it seems strategically sound, "oh, i betcha they couldn't fuck gcc/glibc without gnat -- well, what if it can be denied!!!"
(trilema) mircea_popescu: the issue isn't "use of gnat", the issue is, defanging of gcc/glibc/shitgnome ecosystem.
(trilema) 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.
(trilema) 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.
(trilema) 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.
(trilema) 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
(trilema) trinque: http://btcbase.org/log/2019-03-01#1899852 << so far we have signatures on glibc's death warrant from myself and asciilifeform iirc
(trilema) asciilifeform: 'November 2, 2008 Cross compiling gcc's c++ support doesn't work because even though I'm saying --enable-threads=posix the various subdirectories are trying to run the compiler it built to grep out the "Thread model: " line to set the config entry target_thread_file (which gets used to set glibcxx_thread_h, which is breaking) and you CAN'T RUN IT WHEN WE'RE CROSS COMPILING YOU TWIT!'
(trilema) 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.
(trilema) 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 ?
(trilema) mircea_popescu: ie, the fact that glibc doesn't come with sane memory allocator ~is a failure of glibc~.
(trilema) asciilifeform: ( glibc & co. do not handle devices, impose memory organization scheme , etc )
(trilema) 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.
(trilema) 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.
(trilema) diana_coman considers eating treebark: ate it before, certainly better than eating glibc-barf
(trilema) asciilifeform: ( asciilifeform is for instance at this very moment sitting on a glibcistic gentoo box, but where all tmsr soft is musltronic )
(trilema) 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
(trilema) 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
(trilema) mircea_popescu: diana_coman looks like it's going the way of cuntoo-ada-musl, no glibc.
(trilema) 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)
(trilema) mircea_popescu: this pretty much bans glibc, from my unexpert cursory look it dun seem fixable for sjlj.
(trilema) asciilifeform: mircea_popescu: cuntoo is arguably a realtime test lab for 'what does removing glibc from ~errything~ cost'
(trilema) mircea_popescu: can import glibc 3.x or w/e.
(trilema) 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)
(trilema) 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.)
(trilema) asciilifeform: ( e.g. 'bash bug', also drepper , also via glibc )
(trilema) asciilifeform: glibc is simply poison.
(trilema) mircea_popescu: yes, no glibc was in fact a preference, and we got it out, of trb, of eulora, etc. no argument there.
(trilema) asciilifeform: this was a 2015 find. after which asciilifeform immediately proceeded to get glibc the hell out of trb.
(trilema) asciilifeform: when uncovered that drepper (maintainer of glibc) deliberately broke static linkage globally
(trilema) a111: Logged on 2015-04-29 16:28 mod6: so libnss is dynamically compiled and built/linked to glibc, and can not be avoided?
(trilema) asciilifeform: was found that glibc actually prohibits static linkage.
(trilema) asciilifeform: mircea_popescu: imho the near-term thing to do is for bvt to get the gcc5sim, glibcism, out of his test setup. then can proceed to fix bugs that we actually have in the house, rather than liquishit that only afflicts glibctards.
(trilema) 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
(trilema) asciilifeform: glibc has 0 biz in tmsr proggy.
(trilema) mircea_popescu: well, could also link against musl, ban glibc
(trilema) mircea_popescu: zcx doesn't work, sjlj is broken and glibc is beyond salvation.
(trilema) 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!!!"
(trilema) 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
(trilema) asciilifeform: ( and already produced a self-contained, glibc-free retargetable gnat, works a++ for e.g. arm64 )
(trilema) trinque: this would be expected if the bootstrap compiler requires a host glibc.
(trilema) trinque: ave1: built with itself, but ever on a system without glibc?
(trilema) 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.
(trilema) mircea_popescu: it'll be so fucking splendid to link a bitcoin without glibc jaysus
(trilema) 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"
(trilema) asciilifeform: but localized the boojum to 'libnss' (which turned out to be component of glibc, and not removable)
(trilema) 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
(trilema) asciilifeform: trinque: i was never able to build it under orginary glibc either.
(trilema) 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.
(trilema) asciilifeform: was it actually a hairball of glibcish dependencies ? or build cleanly
(trilema) 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
(trilema) 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
(trilema) 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
(trilema) 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...'
(trilema) asciilifeform: they have option of ditching glibc, say. which hadnt then.
(trilema) phf: ave1: this is trying to build on a glibc x86_64 debian 8.10
(trilema) 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.
(trilema) asciilifeform: sorta like glibc does with dns.
(trilema) 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 !!
(trilema) 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?
(trilema) 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.
(trilema) 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.
(trilema) 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.
(trilema) trinque: musl will "break" where it refused to implement glibc feature-creep outside the posix libc standard. it's a stricter implementation.
(trilema) 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.
(trilema) asciilifeform: ave1: this is The Right Thing, let glibc go to the bottom of the sea where it belongs.
(trilema) 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?
(trilema) 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
(trilema) 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
(trilema) asciilifeform: the only way to muslate on a conventional (glibc) box, is via the rotor method.
(trilema) 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
(trilema) asciilifeform: when i ditch the last glibctronic gentoos, it won't be a day too soon.
(trilema) 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.
(trilema) 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
(trilema) 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 )
(trilema) phf: emacs does the same thing, except in order to do image dump it used some internal glibc (!!!) hack
(trilema) 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.
(trilema) 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.
(trilema) 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
(trilema) ave1: it does not matter if the linux is glibc or musl, I tested also on a clean ubuntu arm64 image
(trilema) ave1: the static binaries, being static, run on all linuxes be it glibc or musl
(trilema) ave1: Yes, 2.14 (this was to find out if I could make glibc produce smaller statically build outputs)
(trilema) ave1: It may also be something with the gmake on this machine, an earlier glibc also failed to build in parallel
(trilema) ave1: I made a mistake on the earlier assertion, it works on glibc machines
(trilema) asciilifeform: because atm all i've got is glibcmachines
(trilema) asciilifeform: what 'won't work on glibc machines'
(trilema) 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
(trilema) ascii_lander: but on those you gotta be yourself statically linked (rather than trying to load glibc)
(trilema) 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
(trilema) 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.
(trilema) 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.
(trilema) mircea_popescu: dudes take glibc and fucking shove it.
(trilema) asciilifeform: ( picture the elephantine drepper glibc in every bin )
(trilema) 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.'
(trilema) 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.
(trilema) 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
(trilema) asciilifeform attempts a build of traditional stator trb inside netbsd ( as rotor is unnecessary there, there is no drepper glibc )
(trilema) asciilifeform: ( you can't dns from a statically linked glibc. but this does not bother me )
(trilema) asciilifeform: or that glibc imports drepper's 0days for you
(trilema) trinque: I dug a glibc trench for now while I fiddle with musl+X
(trilema) asciilifeform: glibc is also not supported for trb.
(trilema) lobbes: Perhaps musl is better option? Fwiw, I posted over on gentoo forumz with my specifics, but am not versed enough to know if the suggestions they gave (e.g. using glibc) will fuck me over building trb or not: https://forums.gentoo.org/viewtopic-t-1062324.html?sid=c3ea68da31445ec3e870e5344a443dd3
(trilema) lobbes: So, I'm midway through my first gentoo adventure. Currently on the compile kernel step (genkernel), but running into funkiness with uClibc errors. My question is: if I abandon uClibc for, say, glibc, will I have issues building trb? (I remember reading in logz that trb doesn't use glibc)
(trilema) Framedragger: asciilifeform: ah, only glibc etc if "recvfrom" in keywords, you're right. but if only "recv" (https://codesearch.debian.net/search?q=recv+.*+MSG_PEEK&page=1), then lots of results
(trilema) asciilifeform: Framedragger: it seems to find strictly 1) glibc 2) quake (?!)
(trilema) asciilifeform: lulcoinz: it's the bitcoin you used in 2011. ~21,000 lines, and shrinking. ( and no 'headers-first' pseudo-verification idiocy, no leveldb, no p2sh, no githubism, no dns, no glibc, various other 'noes'. large collection of exquisite noes.)
(trilema) asciilifeform: mircea_popescu: the glibc6 thing was a quite deliberate bomb to lock out users of old debians and similar
(trilema) mircea_popescu: because "/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.15' not found"
(trilema) asciilifeform: mircea_popescu: just when you thought this can't get any lulzier: '...resource exhaustion issues which can be triggered only with crafted patterns (either during compilation or execution) are not treated as security bugs.' ( https://sourceware.org/glibc/wiki/Security%20Exceptions )
(trilema) phf: who knows with threads, i wouldn't be surprised if sbcl touches them in very inappropriate, glibc specific ways
(trilema) asciilifeform: (iirc all versions of emacs from past decade or so have some kind of perverse hardcoded reliance on glibc in particular)
(trilema) mircea_popescu: glibc is already frozen pre 5
(trilema) asciilifeform: trinque: recall, the drepperites are getting ready to break glibc so that no moar clasical emacs.
(trilema) a111: Logged on 2016-12-29 03:06 asciilifeform: socket.c:(.text.__gnat_gethostbyaddr+0x1a): warning: Using 'gethostbyaddr_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
(trilema) asciilifeform: mircea_popescu: it's the crapola from ye olde glibc
(trilema) mircea_popescu: "Using 'getservbyport_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking" << what THE FUCK does this even mean.
(trilema) asciilifeform: ^ for the record. glibc retardation -- spreads.
(trilema) asciilifeform: socket.c:(.text.__gnat_getservbyport+0xc): warning: Using 'getservbyport_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
(trilema) asciilifeform: socket.c:(.text.__gnat_getservbyname+0xc): warning: Using 'getservbyname_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
(trilema) asciilifeform: socket.c:(.text.__gnat_gethostbyaddr+0x1a): warning: Using 'gethostbyaddr_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
(trilema) asciilifeform: socket.c:(.text.__gnat_gethostbyname+0xf): warning: Using 'gethostbyname_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
(trilema) trinque: asciilifeform: yeah, when I run my gentoo recipe, it's usually musl unless I actually need the glibc turd for something
(trilema) phf: it's a glibc2 variant, i wonder what openbsd does..
(trilema) asciilifeform: buildroot, at least as seen in 'rotor', is not necessary on bsd!! there is no glibc there !! afaik static linking works normally on known bsd
(trilema) asciilifeform: trinque: there is 'nexus of hierarchy' where we, e.g., study writings of mircea_popescu because they make sense and worth respect. and there is the other kind of hierarchy, where prb makes dns query using usg.glibc and internic root server is hardbaked into the code.
(trilema) asciilifeform: (i.e. a box where gcc was built on glibc)
(trilema) asciilifeform: (builds with musl, instead of glibc)
(trilema) asciilifeform: bsd never had glibcism and doesn't really need rotorization
(trilema) asciilifeform: quite like, e.g., glibc's dyn load
(trilema) asciilifeform: trinque: consider a scenario where i review, e.g., glibc
(trilema) assbot: Logged on 20-03-2016 06:27:49; phf: i've managed a reiserfs/lilo combo, though genkernel claims that it doesn't work with reiserfs. uclibc vanilla failed on chroot step, ifconfig and all the other networking bits refused to work. perhaps i needed to grab a uclibc iso? in any case i proceeded witha glibc install for now
(trilema) phf: i've managed a reiserfs/lilo combo, though genkernel claims that it doesn't work with reiserfs. uclibc vanilla failed on chroot step, ifconfig and all the other networking bits refused to work. perhaps i needed to grab a uclibc iso? in any case i proceeded witha glibc install for now
(trilema) asciilifeform: it is a poetteringization of the ordinary glibc execution process
(trilema) asciilifeform: # /etc/localtime is a symlink with glibc > 2.15-41
(trilema) asciilifeform: 'Stallman recently tried what I would call a hostile takeover of the glibc development. He tried to conspire behind my back and persuade the other main developers to take control so that in the end he is in control and can dictate whatever pleases him. This attempt failed ... '
(trilema) mircea_popescu: baked in everywhere, to the level of fucking glibc (what fucking business does glibc have with offering a spurious aliasing service for ips AT ALL ?! that shit belongs three levels below glibc!)
(trilema) assbot: Carlos O'Donell - [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflo ... ( http://bit.ly/1LrHMwR )
(trilema) asciilifeform: Jacmet: the background: i originally picked up buildroot to do an arm system build for an obscure box. and then discovered that it is also the only practical means of compiling with musl instead of glibc, for any system
(trilema) jurov: mod6 well, on another box i updates glibc to same version and perl works fine
(trilema) jurov: asciilifeform: how do i list patches that went into glibc-2.22-r2 ?
(trilema) jurov: i updated glibc with the patch
(trilema) jurov: yes it's likel, i updated glibc, then i said to myself might as well update whole system
(trilema) pete_dushenski: http://log.bitcoin-assets.com/?date=17-02-2016#1408731 << your glibc/musl efforts weren't useless !!!!11
(trilema) asciilifeform: the glibc one or otherwise
(trilema) assbot: GLibc remote exploit affects all Bitcoin clients - except for one. : netsec ... ( http://bit.ly/1LrIj1X )
(trilema) assbot: ScatoshiNukamoto comments on Most Bitcoin Clients Affected By GLIBC DNS Vulnerability ... ( http://bit.ly/1PDB8Yp )
(trilema) assbot: nullc comments on Most Bitcoin Clients Affected By GLIBC DNS Vulnerability ... ( http://bit.ly/1Qjto19 )
(trilema) davout: "we can't remove this thing from our code because it breaks some unnecessary feature, also random reasons maybe" <-> https://www.reddit.com/r/Bitcoin/comments/46354z/most_bitcoin_clients_affected_by_glibc_dns/d027oy0
(trilema) davout: anyway, the glibc dns drama seems to be yielding large amounts of lulz and butthurt
(trilema) assbot: Red Hat, Google Disclose Severe Glibc DNS Vulnerability; Patched But Widespread - Slashdot ... ( http://bit.ly/1RK77Zr )
(trilema) assbot: Nearly All Bitcoin Nodes Affected By Glibc DNS Vulnerability : Buttcoin ... ( http://bit.ly/1RK5ScJ )
(trilema) assbot: Most Bitcoin Clients Affected By GLIBC DNS Vulnerability (Includes Core, Classic, and XT) : btc ... ( http://bit.ly/20BFC4I )
(trilema) asciilifeform: why should the folks who ran glibc still have coin?
(trilema) assbot: Most Bitcoin Clients Affected By GLIBC DNS Vulnerability (Includes Core, Classic, and XT) : btc ... ( http://bit.ly/20BF6DR )
(trilema) assbot: GLibc remote exploit affects all Bitcoin clients - except for one. : netsec ... ( http://bit.ly/1LrIj1X )
(trilema) assbot: GLibc remote exploit affects all Bitcoin clients except for one | Hacker News ... ( http://bit.ly/1LrI6f1 )
(trilema) assbot: Carlos O'Donell - [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflo ... ( http://bit.ly/1LrHMwR )
(trilema) asciilifeform: BingoBoingo: i would add in your article that the flagship trb boxes are running sans-glibc.
(trilema) BingoBoingo: But could be built against glibc so I think my wording is correct.
(trilema) BingoBoingo: <asciilifeform> ~we nuked glibc entirely~ << Nuked the NEED for glibc
(trilema) deedbot-: [Qntra] Google Unveils Glibc DNS Client Vulnerability Many Bitcoin Implementations Affected - http://qntra.net/2016/02/google-unveils-glibc-dns-client-vulnerability-many-bitcoin-implementations-affected/
(trilema) asciilifeform: ~we nuked glibc entirely~
(trilema) assbot: Google Unveils Glibc DNS Client Vulnerability Many Bitcoin Implementations Affected | Qntra ... ( http://bit.ly/1LrHczf )
(trilema) asciilifeform: mircea_popescu: also recall, i excised not only dns but glibc
(trilema) punkman: " The code that causes the vulnerability was introduced in May 2008 as part of glibc 2.9."
(trilema) asciilifeform: ... and the rest of the glibc team '
| →
Download hourly DB snapshot | Get Source Code