tmsr - Search: glibc

400 entries in 0.624s

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

pete_dushenski: sorry, trb sans glibc on netbsd, to be more precise

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 ☟︎

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!

mircea_popescu: <asciilifeform> incidentally the de-glibc-ized trb WILL run on netbsd now! << o hey! ☟︎

assbot: Logged on 20-12-2015 22:01:59; asciilifeform: incidentally the de-glibc-ized trb WILL run on netbsd now!

asciilifeform: incidentally the de-glibc-ized trb WILL run on netbsd now! ☟︎

jurov: last time i binge read glibc info, it ended on strfry

asciilifeform: IT WAS SUPPOSED TO REPLACE GLIBC

asciilifeform: at one time there was a '3' - glibc-free, static, rom-burnable bitcoind. but we have it now.

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"

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" ☟︎

phf: also no re glibc-less binaries

asciilifeform: http://log.bitcoin-assets.com/?date=19-09-2015#1279859 << ever got mlton or smlnj, or mosml, to build glibc-less binaries ? ☝︎

kakobrekla: > It's up to glibc to return it to the kernel and it is poor at that. < ahhh

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

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.

mircea_popescu: doing what, glibc gentoo ?

ascii_field: to get out of glibc !

shinohai is now seeing why ascii_field hates glibc so much

ascii_field: death to glibc.

assbot: glibc steering committee dissolving ... ( http://bit.ly/1K5UcJ3 )

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"

BingoBoingo: Cars fuckign cars, cats and dogs getting along. Drepper really did beat Linus on Glibc didn't he.

ascii_field: mircea_popescu: you just described glibc, l0l

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

mircea_popescu: "early experiments show that statically linked binaries are usually smaller than their dynamically linked glibc counterparts!!!"

assbot: 142 results for 'glibc' : http://s.b-a.link/?q=glibc

ascii_field: !s glibc

ascii_field: phf: i determined, some months ago, that glibc is evil. and decided to abolish it from bitcoin.

mod6: i built mine on a gentoo/nomultilib/glibc x86-64 host

ascii_field: mod6: it uses buildroot to generate a gcc and binutils clean of glibc

ben_vulpes: ascii_field: what's the difference between musl and glibc?

ascii_field: can't use glibc toolchain to build binaries with musl

ascii_field: the binary is a full MB smaller than glibc stator, too

ascii_field: http://dpaste.com/16FR22R.txt << l00k ma, no glibc

asciilifeform unzips, pisses on the grave of glibc

mod6: yeah, trinque. I got the same error [this is on, gentoo/nomultilib/glibc built on 20150713]: http://dpaste.com/27S67FQ.txt

trinque: mod6: gentoo hardened glibc amd64

mod6: what type of environment did you build on? im building mine on [gentoo/nomultilib/glibc]

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.

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.

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 ☝︎

mod6: so I had this build that i created on the 13th: 20150713-v0531-patched-glibc-gentoo-statorBuildScript

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.

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

assbot: Logged on 22-07-2015 19:26:16; ascii_field: yum install gcc libstdc++ gcc-c++ glibc-static

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 ☟︎

hanbot: if glibc on its own is insufficent tho, i have little faith libc6-dev without the -static moniker would work

trinque: hanbot: glibc should already be on there; it is the C standard library most commonly in use on linux

hanbot: does anyone have or know where i can get a glibc-static deb package?

hanbot: meanwhile glibc-static looks unbuntu-friendly, will report back

mircea_popescu: apt-get install gcc libstdc++ gcc-c++ glibc-static

ascii_field: yum install gcc libstdc++ gcc-c++ glibc-static ☟︎

mod6: hanbot: ok so to complete your mission. you'll need a x86-64 / glibc linux environment - gentoo is great, others ok probably too.

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

mod6: oh and there is a new Gentoo guide for nomultilib/glibc -- I created it yesterday & trinque verified as well:

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.

mod6: gentoo nomultilib glibc: 322021

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

mod6: http://thebitcoin.foundation/misc/gentoo-amd64-nomultilib-glibc-20150713-statorBuildScript-buildlog.txt

mod6: http://thebitcoin.foundation/misc/gentoo-amd64-nomultilib-glibc-20150713-AutoStaticv006-buildlog.txt

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.

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 ☝︎

mircea_popescu: http://www.etalabs.net/compare_libcs.html << check out glibc beating the shit out of everyone @strlen and strchr

asciilifeform: punkman: it's an interim thing. still need to shoot glibc in the head

mod6: except this is with glibc huh

trinque: yeah but this is glibc

mod6: that btw, was built on x86-64 deb6/glibc env.

ascii_field: presently i suspect that 'musl' is the only glibc replacement that has any promise

trinque: no glibc and gentoo hardened

ascii_field: or ordinary glibc

decimation: what I find amusing is that gcc comes with system include files, but 'also depends' on glibc

ascii_field: 'hey hey, ho ho,' glibc 'has got to go'

decimation: ascii_field: this must be a glibc vs gcc conflict?

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...

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

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... ☝︎☟︎

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). ☟︎☟︎

ascii_field: not really. if you invoke dns at all in a glibc proggy, you get the libnss idiocy

ascii_field: which, in practice, requires a whole toolchain built against the custom glibc

ascii_field: and apparently the only way to remove it is to build glibc from scratch and link against it

ascii_field: thing even builds statically with glibc

davout: but it wasn't possible before because of the dynmic dns glibc crap or do i misunderstand something here?

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.

asciilifeform: ben_vulpes: it is coming via glibc

asciilifeform: so far, all i learned is that it can - supposedly - be disabled during glibc build config. but this is not what i want

mircea_popescu: asciilifeform to answer earlier q : i think for thius purpose (running on dulap etc) static glibc is exactly right.

mircea_popescu: you actually managed to get glibc to static ?

asciilifeform: mircea_popescu: partial win, it's still built on (static) glibc

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!

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

mircea_popescu: fully expecting he will have to install vanrish, uninstall alsa, recompile the kernel and fix glibc.

asciilifeform: afaik can't do dns at all with static glibc

asciilifeform: (with glibc+static)

asciilifeform: but we have a buildable static(glibc) ibmpc build.

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...

asciilifeform: note that it is still using conventional glibc

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