log
339 entries in 0.48s
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.
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
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)
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
asciilifeform: Framedragger: it seems to find strictly 1) glibc 2) quake (?!)
asciilifeform: a la glibc.
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.)
mircea_popescu: because "/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.15' not found"
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 )
phf: who knows with threads, i wouldn't be surprised if sbcl touches them in very inappropriate, glibc specific ways
asciilifeform: (iirc all versions of emacs from past decade or so have some kind of perverse hardcoded reliance on glibc in particular)
mircea_popescu: glibc is already frozen pre 5
asciilifeform: trinque: recall, the drepperites are getting ready to break glibc so that no moar clasical emacs.
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
asciilifeform: mircea_popescu: it's the crapola from ye olde glibc
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.
asciilifeform: ^ for the record. glibc retardation -- spreads.
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
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
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
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
trinque: asciilifeform: yeah, when I run my gentoo recipe, it's usually musl unless I actually need the glibc turd for something
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
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.
asciilifeform: (i.e. a box where gcc was built on glibc)
asciilifeform: (builds with musl, instead of glibc)
asciilifeform: quite like, e.g., glibc's dyn load
asciilifeform: trinque: consider a scenario where i review, e.g., glibc
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
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
asciilifeform: it is a poetteringization of the ordinary glibc execution process
asciilifeform: # /etc/localtime is a symlink with glibc > 2.15-41
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 ... '
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!)
assbot: Carlos O'Donell - [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflo ... ( http://bit.ly/1LrHMwR )
mircea_popescu: https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html << anyone fuckin looked at o'donell's glibc patch ?
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
jurov: mod6 well, on another box i updates glibc to same version and perl works fine
jurov: asciilifeform: how do i list patches that went into glibc-2.22-r2 ?
jurov: i updated glibc with the patch
jurov: yes it's likel, i updated glibc, then i said to myself might as well update whole system
pete_dushenski: http://log.bitcoin-assets.com/?date=17-02-2016#1408731 << your glibc/musl efforts weren't useless !!!!11 ☝︎
asciilifeform: the glibc one or otherwise
assbot: GLibc remote exploit affects all Bitcoin clients - except for one. : netsec ... ( http://bit.ly/1LrIj1X )
BingoBoingo: alf submission update: "reject: low quality" https://www.reddit.com/r/netsec/comments/4635y5/glibc_remote_exploit_affects_all_bitcoin_clients/
assbot: ScatoshiNukamoto comments on Most Bitcoin Clients Affected By GLIBC DNS Vulnerability ... ( http://bit.ly/1PDB8Yp )
asciilifeform: https://www.reddit.com/r/Bitcoin/comments/46354z/most_bitcoin_clients_affected_by_glibc_dns/d02dax4 << lulzy