70 entries in 0.624s
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?
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?
a111: Logged on 2015-04-06 18:19 mircea_popescu: what's now needed is an expert computer engineer willing and able to take over maintenance of
libnss, starting with fixing it so it allows proper static linking.
a111: Logged on 2015-04-29 16:41 mircea_popescu: you can't go "oh i don't use
libnss anyway". you probably are.
a111: Logged on 2015-04-29 16:28 mod6: so
libnss is dynamically compiled and built/linked to glibc, and can not be avoided?
ascii_field: not really. if you invoke dns at all in a glibc proggy, you get the
libnss idiocy
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
mod6: <+asciilifeform> mod6: not sure how you intend to build a dns-using thing with uclibc << this is a chicken/egg problem yeah. maybe we can't get it fully built because of the whole gethostbyname
libnss bullshit. but if we can at least ensure that it'll link properly, that's huge. then, even if it's not fully statuc because of that, we can amputate dns with your patches and retry.
mircea_popescu: davec originally thought it was
libnss meanwhile found a "retarded languages should be supported too" thing
mircea_popescu: anyway, what would it be doing in bitcoin. waiting for when
libnss is yanked out, to kick in.
jurov: just compile namecoin into
libnss.so :DDDD
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?
mircea_popescu: you can't go "oh i don't use
libnss anyway". you probably are.
☟︎ mircea_popescu: mod6 what i mean is, for as long as you use any sort of function touched, whether you yourself use any of the
libnss "functionality" or not, its gonna be there
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.
ascii_field: note, written prior to the discovery of the
libnss thing
jurov: (and btw, it's different from mozilla's
libnss)
mod6: so
libnss is dynamically compiled and built/linked to glibc, and can not be avoided?
☟︎ mod6: ok maybe that's the part I was missing - how
libnss is somehow tied to glibc.
jurov: the
libnss was done as binary plugin to glibc
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?
☟︎ mircea_popescu: perfect word this. "dude, stop with the bydlokodinga!" "did someone bydlokodinga
libnss ?"
mircea_popescu: what's now needed is an expert computer engineer willing and able to take over maintenance of
libnss, starting with fixing it so it allows proper static linking.
☟︎ mircea_popescu: in the wake of my "who shat the
libnss" investigation tptb have agreed something must be done about this.
ascii_field: "libc", from which come incompatible calls to "
libnss" functions."'
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
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,
assbot: Logged on 05-04-2015 14:21:21; nubbins`: w/e the
libnss thing is. details escape me now.
nubbins`: w/e the
libnss thing is. details escape me now.
☟︎ mircea_popescu: what was bitcoind using that ended up pulling
libnss via glibc ? gethostbyaddr() was it ?
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.
decimation: the
libnss symbols are present therein
decimation: mircea_popescu: re:
libnss < I think it has its roots in solaris
ben_vulpes: mircea_popescu: "linked at all" << (bear with my unsavvy, please) so gcc instructed to build statically should fail to link
libnss because it dynamically links to system libs, but gcc instructed to build dynamicall should not fail under these conditions?
mircea_popescu: then rms has to catch hell about "not supporting lldb". how about you know, taking
libnss the fuck out with a hot poker.
mircea_popescu: the bug discovered in gcc is that it allows
libnss to even be linked AT ALL.
ben_vulpes: so the 'static' build i produced on my deb 6 VM wasn't *truly* static, but claimed to be even though it dynamically linked into
libnss on whatever system on which it ran successfully?
mircea_popescu: asciilifeform it's outrageous, but hey. can you evaluate the time needeed to patch
libnss into behaving correctly ?
mircea_popescu: asciilifeform & wimc : so rms sez he never heard of
libnss before, and can't even recall what it does.
mircea_popescu: so far, i'm a) chasing whoever the fuck broke the world by making an idiotic
libnss and b) unconvinced the problem's more than that dns bs.
mircea_popescu: "why do we have dns ? it sucks! " "yes but that's how nsa could figure out how to diddle via
libnss"
mircea_popescu: asciilifeform do you even have a clue why the fuck
libnss is made that way ?
mircea_popescu: but otherwise, in vast majority of cases,
libnss SHOULD JUST CONTAIN ALL!
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."
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."
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."