400 entries in 0.74s
mod6: either have I, but
glibc is full of trickery.
trinque: I have no strong opinion regarding uclibc vs
glibc, as I haven't used the former at all before this
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
trinque: it diddles
glibc internal preprocessor flags, so on
ben_vulpes: justJanne: have you been following the
glibc travails?
trinque: mircea_popescu: does seem that we keep encountering the rot of
glibc 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 trinque: asciilifeform: turns out dieharder uses internal
glibc preprocessor directives which cause it to explode when built as c99
trinque: ben_vulpes: probably faster than waiting for a
glibc fix :^)
trinque: this guy's making me write a test program to fix an include in
glibc trinque: tragedy of the commons; everyone fucks
glibc and no one pays her medical bills
mircea_popescu: trinque we were looking for someone to fix
glibc earlier too
trinque: and I will, if only as an exercise in whether it's actually possible to get something fixed in
glibc trinque: guy sends me to go bother whoever can fix
glibc trinque: seems this is actually
glibc fuckery re: dieharder
trinque: mircea_popescu: seems it might've worked against an older
glibc davout: from what i grasped, the issue is that
glibc is pulling some random bits in, dynamically
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.
mod6: ahh, so this is for embedded systems -- to replace a bulky/asinine
glibc?
mircea_popescu: asciilifeform heh, so far nobody even compiles
glibc. go away with your exotic temptations, fair lady.
mircea_popescu: ben_vulpes it ends up pulled through
glibc which is the source of this poison
mircea_popescu: but it can't be started from the
glibc i don't think. that's the middle.
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?
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.
mod6: so libnss is dynamically compiled and built/linked to
glibc, and can not be avoided?
☟︎ jurov: thus truly statical compilation of
glibc is impossbile
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 jurov: mod6 i can explain, too. to support different configurations for DNS/users/whatever resolving without
glibc recompilation and without interprocess communication
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?
☟︎ trinque: with the normal
glibc, not any of the alternatives
mircea_popescu: let's make
glibc no longer compile statically and github not work. that'll make the foss so much better.
nubbins`: " The problem comes, I think, mainly from statically linking other
GLIBC libraries, notably "libpthread"" <<< we're using that one
ascii_field: mircea_popescu: i began reading the
glibc source last night
mircea_popescu: you will be helped by the
glibc team but you.absolutely.must.know.what.you're.doing.
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,
decimation: asciilifeform: part of the problem is that
glibc has a 'colorful' history
decimation: I didn't see it. So " --enable-static-nss" is useful for
glibc mircea_popescu: what was bitcoind using that ended up pulling libnss via
glibc ? gethostbyaddr() was it ?
decimation: the amount of bloat in
glibc is quite shocking
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: ok from uclibc docs/Glibc_vs_uClibc_Differences.txt
decimation: well, the redhat
glibc static build is pretty much just building
glibc with -static
decimation: ascii_modem: did you see the earlier note about
glibc compiled statically
decimation: it is apparently possible to create a static
glibc 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."
decimation: yes, the traditional
glibc/dns client shit is quite turdly
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"
☟︎ 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 !?
assbot: Bug #4295: Issue between aspectator and new
glibc at different architectures - C Instrumentation Framework - Open-Source Projects ... (
http://bit.ly/1EeRsYG )
mircea_popescu: decimation: re:
glibc bug << was this an ulrich drepperism? << quite likely.
BingoBoingo: 9 years ago the debian official random number was 6. Now
glibc fuckery is uncovered. Imperial nudity advances.
decimation: re:
glibc bug << was this an ulrich drepperism?
assbot: oss-security - Qualys Security Advisory CVE-2015-0235 - GHOST:
glibc gethostbyname buffer overflow ... (
http://bit.ly/1zr7C2Y )