400 entries in 0.711s
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
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.
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
ossabot: Logged on 2019-11-12 17:07:58 jfw: I expect that'd be quite difficult, its libGL is a
glibc-based .so
jfw: I expect that'd be quite difficult, its libGL is a
glibc-based .so
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?
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.
spyked: ugh, dunno why it asks for
glibc. the only specific item it might require would be kernel knob for counters or whatever.
trinque: learn about runit or hell
glibc trinque: mod6: this is expected; they're linked with
glibc 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?
mircea_popescu: it seems strategically sound, "oh, i betcha they couldn't fuck gcc/
glibc without gnat -- well, what if it can be denied!!!"
mircea_popescu: the issue isn't "use of gnat", the issue is, defanging of gcc/
glibc/shitgnome ecosystem.
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.
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.
☝︎☟︎ 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.
☝︎ 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.
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 ?
mircea_popescu: ie, the fact that
glibc doesn't come with sane memory allocator ~is a failure of
glibc~.
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.
diana_coman considers eating treebark: ate it before, certainly better than eating
glibc-barf
mircea_popescu: diana_coman looks like it's going the way of cuntoo-ada-musl, no
glibc.
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)
mircea_popescu: this pretty much bans
glibc, from my unexpert cursory look it dun seem fixable for sjlj.
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.)
mircea_popescu: yes, no
glibc was in fact a preference, and we got it out, of trb, of eulora, etc. no argument there.
a111: Logged on 2015-04-29 16:28 mod6: so libnss is dynamically compiled and built/linked to
glibc, and can not be avoided?
mircea_popescu: zcx doesn't work, sjlj is broken and
glibc is beyond salvation.
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!!!"
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
trinque: this would be expected if the bootstrap compiler requires a host
glibc.
trinque: ave1: built with itself, but ever on a system without
glibc?
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.
mircea_popescu: it'll be so fucking splendid to link a bitcoin without
glibc jaysus
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"
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.
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
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.
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.
☟︎☟︎ 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
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)
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
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)