← | Results 251 ... 470 found in all logged channels for 'glibc'
(trilema) 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) assbot: Google Online Security Blog: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow ... ( http://bit.ly/1LrFhL1 )
(trilema) assbot: Removing support for Emacs unexec from Glibc [LWN.net] ... ( http://bit.ly/1QO2Zr2 )
(trilema) asciilifeform: pete_dushenski: also recall the glibc agonies
(trilema) guruvan: that's on today's agenda is to see why my glibc fails out of the latest portage :P
(trilema) BingoBoingo: And Glibc DNS functions force dynamic linking which is why excised from trb
(trilema) asciilifeform: esp. now that it ACTUALLY WORKS because no more idiot glibc crud
(trilema) asciilifeform: this is necessary when running a musl executable on a heathen (glibc) linux
(trilema) assbot: Logged on 21-12-2015 21:09:59; pete_dushenski: e. also, that glibc is advertised as an 'essential' component of unix osen, but that it's very much something of a flying spaghetti monster
(trilema) assbot: Logged on 21-12-2015 21:09:58; pete_dushenski: and after actually reading up a bit on glibc instead of telling myself "oh that's nice, alf's done another miraculous thing, which'd be the third this week, each of which is so miraculous that idkwtf it is, if it even applies to anything in my universe", i found that one of the glibc maintainers is florian weimar of http://qntra.net/2015/09/many-network-appliances-leak-master-tls-private-keys-through
(trilema) asciilifeform: (the de-glibc-ation)
(trilema) assbot: Logged on 21-12-2015 21:09:58; pete_dushenski: and after actually reading up a bit on glibc instead of telling myself "oh that's nice, alf's done another miraculous thing, which'd be the third this week, each of which is so miraculous that idkwtf it is, if it even applies to anything in my universe", i found that one of the glibc maintainers is florian weimar of http://qntra.net/2015/09/many-network-appliances-leak-master-tls-private-keys-through
(trilema) pete_dushenski: though 15 minutes of reading was all it took to appreciate the enormity of alf's glibcless netbsd.
(trilema) pete_dushenski: e. also, that glibc is advertised as an 'essential' component of unix osen, but that it's very much something of a flying spaghetti monster
(trilema) pete_dushenski: and after actually reading up a bit on glibc instead of telling myself "oh that's nice, alf's done another miraculous thing, which'd be the third this week, each of which is so miraculous that idkwtf it is, if it even applies to anything in my universe", i found that one of the glibc maintainers is florian weimar of http://qntra.net/2015/09/many-network-appliances-leak-master-tls-private-keys-through-forward-secrecy/
(trilema) assbot: Logged on 21-12-2015 06:25:36; pete_dushenski: besides, is not trb news the dominion of mod6 'state of bitcoin addresses' or qntra ? i can certainly qntra, but i guess i'm not equipped to appreciate the significance of glibc-less-netbsd
(trilema) pete_dushenski: sorry, trb sans glibc on netbsd, to be more precise
(trilema) pete_dushenski: besides, is not trb news the dominion of mod6 'state of bitcoin addresses' or qntra ? i can certainly qntra, but i guess i'm not equipped to appreciate the significance of glibc-less-netbsd
(trilema) assbot: Logged on 21-12-2015 00:03:55; mircea_popescu: <asciilifeform> incidentally the de-glibc-ized trb WILL run on netbsd now! << o hey!
(trilema) mircea_popescu: <asciilifeform> incidentally the de-glibc-ized trb WILL run on netbsd now! << o hey!
(trilema) assbot: Logged on 20-12-2015 22:01:59; asciilifeform: incidentally the de-glibc-ized trb WILL run on netbsd now!
(trilema) asciilifeform: incidentally the de-glibc-ized trb WILL run on netbsd now!
(trilema) jurov: last time i binge read glibc info, it ended on strfry
(trilema) asciilifeform: IT WAS SUPPOSED TO REPLACE GLIBC
(trilema) asciilifeform: at one time there was a '3' - glibc-free, static, rom-burnable bitcoind. but we have it now.
(trilema) assbot: Logged on 19-09-2015 22:55:01; phf: presumably it's either glibc and small binaries or no glibc and the entire stdlib attached to the thing. ocaml at least doesn't do any sort of "tree shaking"
(trilema) phf: presumably it's either glibc and small binaries or no glibc and the entire stdlib attached to the thing. ocaml at least doesn't do any sort of "tree shaking"
(trilema) phf: also no re glibc-less binaries
(trilema) asciilifeform: http://log.bitcoin-assets.com/?date=19-09-2015#1279859 << ever got mlton or smlnj, or mosml, to build glibc-less binaries ?
(trilema) kakobrekla: > It's up to glibc to return it to the kernel and it is poor at that. < ahhh
(trilema) mod6: So Shinohai and I just got done testing my TEST2 bundle with rotor script. We've built successfully on: Gentoo/glibc, Ubuntu 10.04, Debian 6 and Debian 8 :: All x86_64
(trilema) mod6: was a gentoo/glibc environement -- compiled buildroot with the musl settings. didn't change anything to the "rotor" steps execept for adding the change to BDB configure options in trinque's message.
(trilema) mircea_popescu: doing what, glibc gentoo ?
(trilema) ascii_field: to get out of glibc !
(trilema) shinohai is now seeing why ascii_field hates glibc so much
(trilema) ascii_field: death to glibc.
(trilema) assbot: glibc steering committee dissolving ... ( http://bit.ly/1K5UcJ3 )
(trilema) BingoBoingo: "Note that the status of the bug was changed from "RESOLVED INVALID" to "RESOLVED FIXED" in 2014-03-20. Probably because as well as I know Ulrich currently doesn't work in Red Hat and doesn't have any commit access. http://permalink.gmane.org/gmane.comp.lib.glibc.alpha/19088"
(trilema) BingoBoingo: Cars fuckign cars, cats and dogs getting along. Drepper really did beat Linus on Glibc didn't he.
(trilema) ascii_field: mircea_popescu: you just described glibc, l0l
(trilema) asciilifeform: the main allure, for me, was 1) drepper goes to the furnace where he belongs; no glibc 2) can switch cpu arch by turning a knob
(trilema) mircea_popescu: "early experiments show that statically linked binaries are usually smaller than their dynamically linked glibc counterparts!!!"
(trilema) assbot: 142 results for 'glibc' : http://s.b-a.link/?q=glibc
(trilema) ascii_field: phf: i determined, some months ago, that glibc is evil. and decided to abolish it from bitcoin.
(trilema) mod6: i built mine on a gentoo/nomultilib/glibc x86-64 host
(trilema) ascii_field: mod6: it uses buildroot to generate a gcc and binutils clean of glibc
(trilema) ben_vulpes: ascii_field: what's the difference between musl and glibc?
(trilema) ascii_field: can't use glibc toolchain to build binaries with musl
(trilema) ascii_field: the binary is a full MB smaller than glibc stator, too
(trilema) asciilifeform unzips, pisses on the grave of glibc
(trilema) mod6: yeah, trinque. I got the same error [this is on, gentoo/nomultilib/glibc built on 20150713]: http://dpaste.com/27S67FQ.txt
(trilema) trinque: mod6: gentoo hardened glibc amd64
(trilema) mod6: what type of environment did you build on? im building mine on [gentoo/nomultilib/glibc]
(trilema) mod6: my plan for tonight is to put out the bitcoin-v0_5_4-TEST1.tar.gz bundle to the ML tonight if possible. This is a pre-patched tarball of all of ascii's patches (and one of my fixes) up through verifyall. Should work only on x86-64 deb6/ubuntu 14.04/gentoo nomultilib glibc - if anyone wants to help test.
(trilema) mod6: I was able to build on deb6/gentoo nomultilib glibc/and ubuntu 14.04 just fine. On ubuntu, my problem was missing realpath. DEERP.
(trilema) hanbot: package names should be the same, yeah. only package i haven't been able to find in .deb form is glibc-static, see http://log.bitcoin-assets.com/?date=23-07-2015#1210151
(trilema) mod6: so I had this build that i created on the 13th: 20150713-v0531-patched-glibc-gentoo-statorBuildScript
(trilema) mod6: it was: gentoo x86-64 glibc: v0.5.3.1+{ these patches in this order: http://dpaste.com/1CSFS1A.txt } built with stator build script. connected to: 195.211.154.159:8333 running with verifyall - ran great up until a few days back. we discussed this.
(trilema) assbot: Logged on 23-07-2015 01:20:23; mod6: my one gentoo (all ascii's patches through verifyall x86-64/glibc) build got all the way up to where nsl is wedged. but my openbsd one is crawling along on verify all also... so far: height=220047
(trilema) assbot: Logged on 22-07-2015 19:26:16; ascii_field: yum install gcc libstdc++ gcc-c++ glibc-static
(trilema) mod6: my one gentoo (all ascii's patches through verifyall x86-64/glibc) build got all the way up to where nsl is wedged. but my openbsd one is crawling along on verify all also... so far: height=220047
(trilema) hanbot: if glibc on its own is insufficent tho, i have little faith libc6-dev without the -static moniker would work
(trilema) trinque: hanbot: glibc should already be on there; it is the C standard library most commonly in use on linux
(trilema) hanbot: does anyone have or know where i can get a glibc-static deb package?
(trilema) hanbot: meanwhile glibc-static looks unbuntu-friendly, will report back
(trilema) mircea_popescu: apt-get install gcc libstdc++ gcc-c++ glibc-static
(trilema) ascii_field: yum install gcc libstdc++ gcc-c++ glibc-static
(trilema) mod6: hanbot: ok so to complete your mission. you'll need a x86-64 / glibc linux environment - gentoo is great, others ok probably too.
(trilema) mod6: So in addition to lastnight's script I posted [ pulls down ascii's latest patches (up through -verifyall) and applies them to v0.5.3.1 ], I've got an updated one that i've just tested & worked for me on x86-64 gentoo w/glibc: http://dpaste.com/2F68T3F.txt
(trilema) mod6: oh and there is a new Gentoo guide for nomultilib/glibc -- I created it yesterday & trinque verified as well:
(trilema) mod6: one other thing I gotta do is update the gentoo-uclibc guide to a new guide for nomultilib glibc, should be fairly easy. then test it on my pos box.
(trilema) mod6: gentoo nomultilib glibc: 322021
(trilema) mod6: As far as testing, so far everything seems to be working ok -- i've fully sync'd 1 stator build, and i've got 2 more full sync's running curretly: one gentoo x86-64 w/glibc & one OpenBSD x86-64 w/glibc
(trilema) asciilifeform: btw this is a glibcism!
(trilema) mod6: So over the weekend and today, was working on building a new gentoo-amd64-nomultilib (glibc) instance to test out application of patches with v0.5.3.1-RELEASE as the base. Was able to build static binaries with gentoo & glibc just fine with both a modified auto-static (auto.sh) and with a slightly modified stator.sh script.
(trilema) mod6: in particular, this test will be with vanilla gcc (glibc) and not uclibc. With uclibc, I had to do some extra tweaks: http://log.bitcoin-assets.com/?date=11-06-2015#1160161
(trilema) mircea_popescu: http://www.etalabs.net/compare_libcs.html << check out glibc beating the shit out of everyone @strlen and strchr
(trilema) asciilifeform: punkman: it's an interim thing. still need to shoot glibc in the head
(trilema) mod6: except this is with glibc huh
(trilema) trinque: yeah but this is glibc
(trilema) mod6: that btw, was built on x86-64 deb6/glibc env.
(trilema) ascii_field: presently i suspect that 'musl' is the only glibc replacement that has any promise
(trilema) trinque: no glibc and gentoo hardened
(trilema) ascii_field: or ordinary glibc
(trilema) decimation: what I find amusing is that gcc comes with system include files, but 'also depends' on glibc
(trilema) ascii_field: 'hey hey, ho ho,' glibc 'has got to go'
(trilema) decimation: ascii_field: this must be a glibc vs gcc conflict?
(trilema) assbot: Logged on 01-07-2015 14:49:54; mircea_popescu: http://log.bitcoin-assets.com/?date=29-06-2015#1181240 << the one thing left loose is that AFTER such, rms is not saying, to me or to anyone, "hey, drepper moved to the dark side, glibc was forked". the last thing you'd expect rms to be indicted for would be an inclination to "make things work" and fold for convenience rather than stand for principle. nevertheless...
(trilema) mircea_popescu: http://log.bitcoin-assets.com/?date=29-06-2015#1181240 << the one thing left loose is that AFTER such, rms is not saying, to me or to anyone, "hey, drepper moved to the dark side, glibc was forked". the last thing you'd expect rms to be indicted for would be an inclination to "make things work" and fold for convenience rather than stand for principle. nevertheless...
(trilema) assbot: Logged on 29-06-2015 20:38:44; ascii_field: '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 but he kept on pressuring people everywhere and it got really ugly. In the end I agreed to the creation of a so-called "steering c
(trilema) assbot: Logged on 29-06-2015 20:38:44; ascii_field: '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 but he kept on pressuring people everywhere and it got really ugly. In the end I agreed to the creation of a so-called "steering c
(trilema) ascii_field: '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 but he kept on pressuring people everywhere and it got really ugly. In the end I agreed to the creation of a so-called "steering committee" (SC).
(trilema) ascii_field: not really. if you invoke dns at all in a glibc proggy, you get the libnss idiocy
(trilema) ascii_field: which, in practice, requires a whole toolchain built against the custom glibc
(trilema) ascii_field: and apparently the only way to remove it is to build glibc from scratch and link against it
(trilema) ascii_field: thing even builds statically with glibc
(trilema) davout: but it wasn't possible before because of the dynmic dns glibc crap or do i misunderstand something here?
(trilema) mod6: <+asciilifeform> anybody build that thing ? << i did try to build your "stator" tarball from lastnight. i provisioned a new deb6 with glibc/gcc-4.5.4, had some issues, never was able to build whole orchestra. I think its perhaps system related.
(trilema) asciilifeform: ben_vulpes: it is coming via glibc
(trilema) asciilifeform: so far, all i learned is that it can - supposedly - be disabled during glibc build config. but this is not what i want
(trilema) mircea_popescu: asciilifeform to answer earlier q : i think for thius purpose (running on dulap etc) static glibc is exactly right.
(trilema) mircea_popescu: you actually managed to get glibc to static ?
(trilema) asciilifeform: mircea_popescu: partial win, it's still built on (static) glibc
(trilema) mod6: If you stripped out all of the DNS stuff and then did a build with gcc/glibc I'm thinking that would get us where we want to be; sounds like you've done that!
(trilema) mod6: <+asciilifeform> now what i can't remember is whether mod6 already had this orchestra working <+asciilifeform> (with glibc+static) << v0.5.3.1-RELEASE basically is not true "static" build because of the gethostbyname() (DNS/libnss) calls in there. but was trying to build static bitcoind with uclibc/gcc on gentoo, was hitting a problem described here before. If you stripped out all of the DNS stuff and then did a build with gcc/glibc I'm thinkin
(trilema) mircea_popescu: fully expecting he will have to install vanrish, uninstall alsa, recompile the kernel and fix glibc.
(trilema) asciilifeform: afaik can't do dns at all with static glibc
(trilema) asciilifeform: (with glibc+static)
(trilema) asciilifeform: but we have a buildable static(glibc) ibmpc build.
(trilema) asciilifeform: mircea_popescu: let me know if you were able to build my 'stator.' and if you think it makes sense to sweat over a uclibc build for ibmpc, where everything ~else~ is sitting on glibc...
(trilema) asciilifeform: note that it is still using conventional glibc
(trilema) mircea_popescu: if this pattern bullshit worked we wouldn't be stuck here with glibc. and that goes exactly to pete_dushenski "wisdom of decisions" thing above too
(trilema) assbot: Bug #134400 “glibc do not really static compile my project.” : Bugs : glibc package : Ubuntu ... ( http://bit.ly/1H4hmSN )
(trilema) asciilifeform: a #pragma in glibc ?
(trilema) mod6: either have I, but glibc is full of trickery.
(trilema) trinque: I have no strong opinion regarding uclibc vs glibc, as I haven't used the former at all before this
(trilema) asciilifeform: glibc belongs in woodchipper regardless
(trilema) trinque: older glibc?
(trilema) mircea_popescu: not just from a "must be in there for we need all the dns-carried pores imported via glibc etc", but also in the much lower level "who's in charge of the it!!1" thing
(trilema) trinque: it diddles glibc internal preprocessor flags, so on
(trilema) mircea_popescu: what, like you stopped using glibc ?
(trilema) ben_vulpes: justJanne: have you been following the glibc travails?
(trilema) trinque: mircea_popescu: does seem that we keep encountering the rot of glibc
(trilema) trinque: ben_vulpes: the actual dieharder code uses glibc internals in a way that used to work, now does not due to as yet undiscovered source of rust, with vague indications that compiling with std=c99 has implications for glibc
(trilema) trinque: asciilifeform: turns out dieharder uses internal glibc preprocessor directives which cause it to explode when built as c99
(trilema) trinque: ben_vulpes: probably faster than waiting for a glibc fix :^)
(trilema) trinque: https://bugs.gentoo.org/show_bug.cgi?id=549754 << specific incantation that breaks the glibc headers
(trilema) trinque: this guy's making me write a test program to fix an include in glibc
(trilema) trinque: tragedy of the commons; everyone fucks glibc and no one pays her medical bills
(trilema) mircea_popescu: trinque we were looking for someone to fix glibc earlier too
(trilema) trinque: and I will, if only as an exercise in whether it's actually possible to get something fixed in glibc
(trilema) trinque: guy sends me to go bother whoever can fix glibc
(trilema) trinque: seems this is actually glibc fuckery re: dieharder
(trilema) trinque: mircea_popescu: seems it might've worked against an older glibc
(trilema) trinque: blowing up inside glibc
(trilema) mircea_popescu: or was, at some point. before glibc
(trilema) trinque: http://log.bitcoin-assets.com/?date=12-05-2015#1128895 << aha. glibc is dead to me. << gentoo's hardened/linux/uclibc/amd64 ?
(trilema) davout: from what i grasped, the issue is that glibc is pulling some random bits in, dynamically
(trilema) asciilifeform: the uniquely idiotic error message, 'not found', refers to glibc and its turds (libnss etc)
(trilema) mircea_popescu: i dunno, by now linux is windowized enough. they can release their shit for systemd/ubuntu/glibc-with-modules/etc and pretty much have it right.
(trilema) mod6: ahh, so this is for embedded systems -- to replace a bulky/asinine glibc?
(trilema) mircea_popescu: asciilifeform heh, so far nobody even compiles glibc. go away with your exotic temptations, fair lady.
(trilema) mircea_popescu: ben_vulpes it ends up pulled through glibc which is the source of this poison
(trilema) assbot: The GNU C Library: glibc iconv Implementation ... ( http://bit.ly/1EM1zFX )
(trilema) mod6: <+ascii_field> http://www.gnu.org/software/libc/manual/html_node/glibc-iconv-Implementation.html << wtf is this thing doing in bitcoind << is this another automagically linked in pos to glibc?
(trilema) assbot: The GNU C Library: glibc iconv Implementation ... ( http://bit.ly/1JMxYk6 )
(trilema) mircea_popescu: but it can't be started from the glibc i don't think. that's the middle.
(trilema) mircea_popescu: mod6 building glibcc "by hand" is not the trivial taks you make it out.
(trilema) mod6: <+jurov> the libnss was done as binary plugin to glibc << so there is no possible way to just build glibc by hand and not include libnss? or there are basically so many things that use libnss that even if you did, stuff wouldn't work anyway?
(trilema) mod6: <+mircea_popescu> ~whether one even uses libnss or not~! << so even if we didn't even call "whatsMyIP()" or w/e it is, this would still be a dingleberry attached to glibc.
(trilema) mod6: so libnss is dynamically compiled and built/linked to glibc, and can not be avoided?
(trilema) jurov: thus truly statical compilation of glibc is impossbile
(trilema) mod6: ok maybe that's the part I was missing - how libnss is somehow tied to glibc.
(trilema) jurov: the libnss was done as binary plugin to glibc
(trilema) jurov: mod6 i can explain, too. to support different configurations for DNS/users/whatever resolving without glibc recompilation and without interprocess communication
(trilema) 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) trinque: with the normal glibc, not any of the alternatives
(trilema) asciilifeform: in other news, #glibc is one of the quietest channels one could imagine short of an entirely dead one.
(trilema) mircea_popescu: let's make glibc no longer compile statically and github not work. that'll make the foss so much better.
(trilema) assbot: Understanding glibc malloc | sploitF-U-N ... ( http://bit.ly/1Ct1SAJ )
(trilema) nubbins`: " The problem comes, I think, mainly from statically linking other GLIBC libraries, notably "libpthread"" <<< we're using that one
(trilema) mircea_popescu: less than glibc. weighs about the same as uc
(trilema) ascii_field: mircea_popescu: i began reading the glibc source last night
(trilema) mircea_popescu: you will be helped by the glibc team but you.absolutely.must.know.what.you're.doing.
(trilema) ascii_field: and other things. It's supposed to make application programs independent of the separately configured actual network environment of the machine. A nice idea, but changes to GLIBC can lead to problems loading it. And you can't statically link "libnss", since it is configured for each machine individually. The problem comes, I think, mainly from statically linking other GLIBC libraries, notably "libpthread", "libm", and
(trilema) ascii_field: '"I suppose the idea is that everything will be in the downloaded file, so nothing depends on the local libraries on the target system. Unfortunately with Linux, and I think anything else using GLIBC, this still isn't quite true. There's this "libnss" (name service switch, some people seem to call it network security system) which provides functions for accessing various databases for authentication, network information,
(trilema) decimation: asciilifeform: part of the problem is that glibc has a 'colorful' history
(trilema) asciilifeform: <decimation> I didn't see it. So " --enable-static-nss" is useful for glibc << as i understand, this results in random breakage (a binary which only runs with any degree of certainty on your machine)
(trilema) asciilifeform: 'I do not know where to find the historic references, but yes, static linking is dead on GNU systems. (I believe it died during the transition from libc4/libc5 to libc6/glibc 2.x.) The feature was deemed useless in light of: Security vulnerabilities. Application which was statically linked doesn't even support upgrade of libc....'
(trilema) decimation: I didn't see it. So " --enable-static-nss" is useful for glibc
(trilema) decimation: http://log.bitcoin-assets.com/?date=05-04-2015#1089276 < I apologize for failing to convey my meaning well. I meant that redhat 'provides' this as a source package, and therefore one could examine exactly how they did it - not to swallow the binary without inspection. Source is here > http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/glibc-2.12-1.149.el6_6.5.src.rpm
(trilema) mircea_popescu: what was bitcoind using that ended up pulling libnss via glibc ? gethostbyaddr() was it ?
(trilema) mircea_popescu: http://log.bitcoin-assets.com/?date=05-04-2015#1089208 << apparently we were not the only ones to notice glibc got raped.
(trilema) decimation: which gives us glibc turdlets
(trilema) decimation: the amount of bloat in glibc is quite shocking
(trilema) decimation: 6) uClibc does not support NSS (/lib/libnss_*), which allows glibc to easily support various methods of authentication and DNS resolution. uClibc only supports flat password files and shadow password files for storing authentication information. If you need something more complex than this, you can compile and install pam.
(trilema) decimation: ok from uclibc docs/Glibc_vs_uClibc_Differences.txt
(trilema) decimation: well, the redhat glibc static build is pretty much just building glibc with -static
(trilema) decimation: ascii_modem: did you see the earlier note about glibc compiled statically
(trilema) decimation: it is apparently possible to create a static glibc
(trilema) assbot: Logged on 02-04-2015 14:54:13; assbot: Logged on 02-04-2015 03:26:58; nubbins`: "glibc uses libnss to support a number of different providers for address resolution services. Unfortunately, you cannot statically link libnss, as exactly what providers it loads depends on the local system's configuration."
(trilema) asciilifeform: 'Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking' << wtf are we even using getaddrinfo for.
(trilema) assbot: Logged on 02-04-2015 03:26:58; nubbins`: "glibc uses libnss to support a number of different providers for address resolution services. Unfortunately, you cannot statically link libnss, as exactly what providers it loads depends on the local system's configuration."
(trilema) assbot: Logged on 02-04-2015 01:18:00; decimation: http://stackoverflow.com/questions/2725255/create-statically-linked-binary-that-uses-getaddrinfo <glibc uses libnss to support a number of different providers for address resolution services. Unfortunately, you cannot statically link libnss, as exactly what providers it loads depends on the local system's configuration.
(trilema) nubbins`: "glibc uses libnss to support a number of different providers for address resolution services. Unfortunately, you cannot statically link libnss, as exactly what providers it loads depends on the local system's configuration."
(trilema) decimation: yes, the traditional glibc/dns client shit is quite turdly
(trilema) decimation: http://stackoverflow.com/questions/2725255/create-statically-linked-binary-that-uses-getaddrinfo <glibc uses libnss to support a number of different providers for address resolution services. Unfortunately, you cannot statically link libnss, as exactly what providers it loads depends on the local system's configuration.
(trilema) 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) mircea_popescu: re " warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking" ascii_field wtf is that shit !?
(trilema) danielpbarron: bitcoind: /usr/lib/arm-linux-gnueabi/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by bitcoind)
(trilema) asciilifeform: just to underscore the sheer level of the braindamage i've uncovered - the thing won't build on any box with past 2+ yrs of glibc.
(trilema) asciilifeform: http://pastebin.com/VkgE27Pd << undoes the shitgnomism, but wtf should i have to rebuild glibc and -everything- to use a perfectly ordinary proggy ?
(trilema) asciilifeform: (and yes, as far as i can tell, the recent glibc pant-shitting was -also- drepper)
(trilema) assbot: Bug #4295: Issue between aspectator and new glibc at different architectures - C Instrumentation Framework - Open-Source Projects ... ( http://bit.ly/1EeRsYG )
(trilema) asciilifeform: the_scourge: 'NixOS 14.12 “Caterpillar” has been released, the third stable release branch. It brings Linux 3.14, systemd 217, Glibc 2.20, KDE 4.14.1, and much more.'
(trilema) punkman: "so 2013 glibc fixed a bug, 2014 google found+fixed the same bug https://code.google.com/p/chromium/issues/detail?id=364511 … and 2015 qualys found it again.."
(trilema) mircea_popescu: decimation: re: glibc bug << was this an ulrich drepperism? << quite likely.
(trilema) BingoBoingo: 9 years ago the debian official random number was 6. Now glibc fuckery is uncovered. Imperial nudity advances.
(trilema) decimation: re: glibc bug << was this an ulrich drepperism?
(trilema) assbot: oss-sec: Re: GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235) ... ( http://bit.ly/18qONRD )
(trilema) assbot: oss-security - Qualys Security Advisory CVE-2015-0235 - GHOST: glibc gethostbyname buffer overflow ... ( http://bit.ly/1zr7C2Y )
(trilema) assbot: sourceware.org Git - glibc.git/commitdiff ... ( http://bit.ly/1yLj1sr )
(trilema) assbot: Bug 1183461 – CVE-2015-0235 glibc: __nss_hostname_digits_dots() heap-based buffer overflow ... ( http://bit.ly/1z6fvHR )
(trilema) mircea_popescu: im sure you can have glibc ported over :D
(trilema) mircea_popescu: pankkake saywut ?! glibc ?
← |
Download hourly DB snapshot | Get Source Code