log☇︎
74 entries in 0.401s
dorion_road: mircea_popescu gcc refers to c compiler, ave1 said he's working on a genesis based on version 4.9.4. By c library I mean the choice essentially between glibc and musl and dynamic and static linking, e.g. http://logs.ossasepia.com/log/trilema/2019-11-27#1953721
ossabot: Logged on 2019-11-12 16:57:31 jfw: It's a Linux distro I put together, in a couple stages, based on gcc 4.7, musl, busybox userland, exclusively static linking
ossabot: Logged on 2019-11-13 18:16:19 bvt: re tmsr os - i am curious what work plan trinque will come up with, esp wrt static linking.
dorion_road: For fundamental strategy decisions such as the static linking knot, I'm really going to have to lean heavily on the technical expertise here.
bvt: re tmsr os - i am curious what work plan trinque will come up with, esp wrt static linking.
trinque: yep, just enumerating. what about bundling the necessary libs alongside. afaik this is what steam does, static linking for idiots
jfw: It's a Linux distro I put together, in a couple stages, based on gcc 4.7, musl, busybox userland, exclusively static linking
asciilifeform: for the l0gz: 'Years ago, a “technical” decision was made by a core gcc developer named Drepper to break static linking. This means that no useful binaries can ever execute on Linux without dynamically linking to certain libraries making the proposition of distributing signed binaries futile, making the proposition of secure software futile, making the proposition of Bitcoin futile, making the proposition of sound money futile, m
asciilifeform: summary in log, iirc was : asciilifeform wrote to rms re the 'libnss' garbage preventing static linking of glibc. rms 0 reply. but when mircea_popescu wrote, rms answered w/ jwzisms.
trinque: upstack, it's not just a step around lack of static linking, but also deterministic reproduction of config state
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.
bvt: i.e. with static linking, all locks are compiled into noops.
bvt: which is broken with static linking due to usual 'creativeness' of gnu folx https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/gthr-posix.h;h=88cbc23937ec20b15b35c5adb7f9983282c6f084;hb=HEAD#l247
asciilifeform: or static linking.
a111: Logged on 2018-07-16 16:44 mircea_popescu: diana_coman note that "binary identity" is not even necessary a premise. you can go "hey shithead, why the fuck are you linking dynamic mysql when there's been a static one for five years". or w/e.
mircea_popescu: diana_coman note that "binary identity" is not even necessary a premise. you can go "hey shithead, why the fuck are you linking dynamic mysql when there's been a static one for five years". or w/e. ☟︎
spyked: diana_coman, I think v.pl will press either side of the http://btcbase.org/patches?patchset=vtools tree (keccak or sha), but not both. also, re. error, vtools_fixes_static_tohex should fix it. I've also encountered the linking error in e.g. http://btcbase.org/log/2018-05-21#1816314 and earlier. ☝︎
mircea_popescu: "no static linking" is how you say "no actual ownership of anything" in the context of computer programming and "i am heavily into consent" is how you say "no static linking" in the context of sexual practice and so fucking following.
asciilifeform: though, i will point out, not on crapple, where static linking is thoroughly impossible as of late
a111: Logged on 2017-06-03 02:35 asciilifeform: ( and prohibits static linking )
asciilifeform: ( and prohibits static linking ) ☟︎
asciilifeform: !~later tell mod6 http://wotpaste.cascadianhacker.com/pastes/upCny/?raw=true << makefile. this will work everywhere but crapple, where static linking is entirely dead. ( will work there also if you discard the relevant flags. )
scriba: Logged on 2017-03-28: [23:51:43] <phf> it's not the static linking that gets you, it's the lack of stable abi. binary loads, but fails to do the right thing on system call
asciilifeform: phf: this was the original drepperist excuse for 'shadow banning' static linking, 'oh forget it, no MODERN!11 os has a stable abi'
phf: it's not the static linking that gets you, it's the lack of stable abi. binary loads, but fails to do the right thing on system call
asciilifeform: that doesn't sound like 'static linking works'
asciilifeform: phf: does static linking work on openbsd ?
a111: Logged on 2016-12-31 18:20 mircea_popescu: but not just llvm - the whole world exists, and it produces things such as "'Static linking of user binaries is not supported on Mac OS X. Tying user binaries to the internal implementation of Mac OS X libraries and interfaces would limit our ability to update and enhance Mac OS X. Instead, dynamic linking is supported (linking against crt1.o automatically instead of looking for crt0.o, for example). We strongly recommend tha
mircea_popescu: static linking doesn't work ? ok then, i import the source.
asciilifeform: (same folx as were responsible for 'prohibiting' static linking. see, if no dynamically-linked crapolade in process memory space, AND deadcode eliminated, then ROP will be quite painful to arrange !!)
a111: Logged on 2016-12-31 18:20 mircea_popescu: but not just llvm - the whole world exists, and it produces things such as "'Static linking of user binaries is not supported on Mac OS X. Tying user binaries to the internal implementation of Mac OS X libraries and interfaces would limit our ability to update and enhance Mac OS X. Instead, dynamic linking is supported (linking against crt1.o automatically instead of looking for crt0.o, for example). We strongly recommend tha
mircea_popescu: but not just llvm - the whole world exists, and it produces things such as "'Static linking of user binaries is not supported on Mac OS X. Tying user binaries to the internal implementation of Mac OS X libraries and interfaces would limit our ability to update and enhance Mac OS X. Instead, dynamic linking is supported (linking against crt1.o automatically instead of looking for crt0.o, for example). We strongly recommend tha ☟︎☟︎
phf: we briefly exploerd this fun fact back when static linking became a thing (with bitcoind)
asciilifeform: 'Static linking of user binaries is not supported on Mac OS X. Tying user binaries to the internal implementation of Mac OS X libraries and interfaces would limit our ability to update and enhance Mac OS X. Instead, dynamic linking is supported (linking against crt1.o automatically instead of looking for crt0.o, for example). We strongly recommend that you consider the limitations of statically linking very carefully, and consider yo
mircea_popescu: they're forcing the latest in static linking deliberate breakage (+ no doubt other goodies) into the "ecosystem"
phf: asciilifeform: ~on all systems~ ~static linking~ of pthread is ~not guaranteed~ to work
asciilifeform: buildroot, at least as seen in 'rotor', is not necessary on bsd!! there is no glibc there !! afaik static linking works normally on known bsd
Framedragger: thestringpuller: yeah you're totally right and i really like the api - it's nice! it does seem that to make sure everything incl hrtf works on a person's PC it needs to be installed to system dirs and then linked dynamically as folks had problems with static linking; and apparently for windows the 'proper' way to do it is to first install creative's openal version, and *then* install openal-soft on top
mircea_popescu: <asciilifeform> but, to briefly rewind, << and following. static linking, not dynamic linking. your "the mechanism described in mircea_popescu's sketch." symbol is not acceptabru.
mircea_popescu: 1 should be easy to expand upon. you are familiar with the issues of maintaining software in the beleaguered c world, from what i've seen in the logs. such as you know, no more static linking now. gotta support utf now. (most relevant here : http://log.bitcoin-assets.com//?date=29-02-2016#1418193 ) ☝︎
mircea_popescu: but... no pogos. because no static linking in gcc. because etc.
phf: openbsd patch as written results in a working build on both linux and openbsd. it introduces necessary ifdefs to ensure cross platform support. the only change that it does to makefile is, at least according to my research, is necessary with some versions of gcc, rather then openbsd specific (has to do with static linking of pthread). without that change build ~can~ produce broken static bitcoind on both openbsd and linux. at the time
ascii_rear: static linking of the whole relevant body of law into the contract
ben_vulpes: static linking is a thing to know about to hack on bitcoin related things
n6: then why did I need to know about static linking?
assbot: Logged on 30-07-2015 01:50:12; mircea_popescu: "Note, this is pretty much contrary to what Ulrich Drepper reckons about static linking." << everywhere a gavin!
mircea_popescu: "Note, this is pretty much contrary to what Ulrich Drepper reckons about static linking." << everywhere a gavin! ☟︎
asciilifeform: mircea_popescu: recall, static linking was Officially Deprecated
mircea_popescu: am i correct in reading between the lines of hanbot's efforts that in point of fact someone carefully packaged a debian/ubuntu "equivalent" of the gcc package that allows static linking which in point of fact and quite pointedly DOES NOT allow static linking ?
ascii_field: 'musl's efficiency is unparalleled in Linux libc implementations. Designed from the ground up for static linking, musl carefully avoids pulling in large amounts of code or data that the application will not use. ... musl features the first post-NPTL implementation of POSIX threads for Linux, and the first aimed at complete conformance and robustness. Thread cancellation has been re-designed to avoid serious race
mats: "There are still too many people out there who think (or even insist) that static linking has benefits. This has never been the case and never will be the case." this guy...
decimation: also, nobody gives a fuck about supporting static linking, news at 11
decimation: with uclib static linking
assbot: Static Linking Considered Harmful ... ( http://bit.ly/1IYonUC )
asciilifeform: btw, i found our shitgnome: http://www.akkadia.org/drepper/no_static_linking.html
decimation: heh yeah only crazies would consider writing cpp for embedded or static linking
mircea_popescu: "The drawback of using loadable objects is not a problem in the GNU C Library, at least on ELF systems. Since the library is able to load shared objects even in statically linked binaries, static linking need not be forbidden in case one wants to use iconv."
mircea_popescu: funkenstein_ static linking of what ? as far as bitcoind specifically goes, iirc nubbins` reported he managed one.
funkenstein_: am i correct in summing up turd polishing discussions, that once DNS is fully removed static linking will be back on the table?
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. ☟︎
ascii_field: essentially, 'this -is- the new static linking. forget about the old one'
ascii_field: 'If you believe "static linking" to mean something else from what I
mircea_popescu: <asciilifeform> -somebody- saw it fit to break static linking on gnu platform in the traditional microshit way - suddenly, silently, and 'for your own good' (TM) << and the fact that silently worked tells mike_c why qntra market cap would reasonably exceed the sum of the market cap of all computing publications available.
asciilifeform: -somebody- saw it fit to break static linking on gnu platform in the traditional microshit way - suddenly, silently, and 'for your own good' (TM)
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....'
assbot: gcc - Linux static linking is dead? - Stack Overflow ... ( http://bit.ly/1D9Q1fS )
asciilifeform: http://stackoverflow.com/questions/3430400/linux-static-linking-is-dead << i'm not remotely the first to notice the gorilla shitting in the kitchen
mircea_popescu: and the failed static linking happens on both ?
ascii_field: mircea_popescu: as you probably suspected, static linking as such is broken on extant systems.
decimation: ok I got it to compile on centos6 but I had to add the following to the end of the linking command line: -static-libgcc -Wl,-Bstatic -l pthread_nonshared -Wl,-Bdynamic -l m -l dl
asciilifeform: mod6: odd. because i ended up with proper static linking
mod6: aight. so yeah, stay tuned. as soon as I get anything working with static libs and static linking of the output object files from the bitcoin source base, I'll give an update.
thestringpuller: what's the benefit of static linking?
thestringpuller: oh dynamically linking vs static