log☇︎
60 entries in 0.886s
asciilifeform: trinque: speaking moar from concrete than theoretical pov -- gcc5 has documented 'optimizations' that remove bounds checks
asciilifeform really must dust off the old notes and try this with own hands; the presence of gcc5 in the build bothers asciilifeform not only from 'practical' but from thompsonistic pov
a111: 2 results for "from:trinque gcc5", http://btcbase.org/log-search?q=from%3Atrinque%20gcc5
asciilifeform: !#s from:trinque gcc5
asciilifeform: spyked: i admit that i still dunget why it needs the gcc5 step
mircea_popescu: around gcc5 times (early 2016) binutils were verschlimmbessert with support of new relocations <<< aaahahahahaha.
bvt: i don't think it gcc5-specific, the patch against this problem that i've seen was written for gcc 4.8
diana_coman: bvt, interesting; is that gcc5-specific though?
asciilifeform: afaik there is exactly 0 win from gcc5+, and plenty of lose.
asciilifeform: i recommend to leave gcc5 entirely alone (unless specifically digging for lulz)
asciilifeform: gcc5 breakage extends into the Ada world << noshit, if yer on a gcc5istic gnat, all bets are off, they fucked the back end
asciilifeform: ( if yer using a heathen gnat, and a gcc5+istic one, it will output the familiar gcc5isms; but we aint using one )
asciilifeform: not having used gcc5+ , i never saw this bug
asciilifeform: the gcc5+ gnomes, occupy selves with cranking out 'mandatory' kludges for intelism; removing backend support for vintage, marginally-sane archs (alpha, hitachi, etc); gluing-with-broken-glass various incompatibilities to prevent coad developed under 5+ from building under 4.x; inserting 'optimizations' that snake around naive cprogrammer attempts at bounds-constraint; and so forth.
asciilifeform: http://btcbase.org/log/2019-01-05#1884619 << from ave1 , i hope to see a 'port' of tmsr-gnat that can be hard-welded into cuntoo as primary gcc ( to remove the hack where it builds gcc5, then down to 4.9, and neither of'em being a gnat ) ☝︎
asciilifeform: upstack, https://archive.is/WMoLv (warning: entomologists only) << the how&why of uboot 'gcc5+ only' idjicy. tldr: gcc5 silently broke uboot on arm. so the latter was 'fixed' so as to... ONLY gcc5+. in the now-customary way.
asciilifeform: i.e. i was not able to build uboot on ANY of my boxen, even on the toilets where gcc5+ exists
asciilifeform: hmm, why does it emerge gcc5 ???
asciilifeform: http://btcbase.org/log/2018-01-21#1773685 << if this is about the 'integer retardation' issue, the 1 thing it quite definitively had 0 to do with , is gcc5 : which did not exist in the era of 0.5.3 , nor did it exist in my stator or rotor setups ☝︎
a111: Logged on 2018-01-21 21:38 trinque: my current wager is folks that had it were using a gcc5, which is defaulted to a later standard for C
trinque: my current wager is folks that had it were using a gcc5, which is defaulted to a later standard for C ☟︎
asciilifeform: in other noose, trinque's pill worked, but the gcc5.x item was not needed
trinque: asciilifeform: https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi/ << related.
asciilifeform: tbh the retardation of gcc5+ dun affect , in any known way, ada -- the rotters rotted c/cpp frontend strictly
asciilifeform: mircea_popescu: principal headache is in re bringing up ~new~ boxes, without gcc5+ crapolade leaking in; rather than keeping old ones going
a111: Logged on 2017-11-25 01:55 asciilifeform: http://btcbase.org/log/2017-11-25#1742977 << having python > 2.7 is quite like having gcc5 around.
asciilifeform: http://btcbase.org/log/2017-11-25#1742977 << having python > 2.7 is quite like having gcc5 around. ☝︎☟︎
asciilifeform: http://btcbase.org/log/2017-11-20#1741187 << the correct solution is to not install the gcc5 nonsense to begin with, then won't need cleaning. but this won't be happening during isp winter ☝︎
asciilifeform: recall, original 'gcc5 is fatally touched' discovery happened on n00bz building rotors
asciilifeform: gcc5 was made by wreckers.
a111: 28 results for "gcc5", http://btcbase.org/log-search?q=gcc5
asciilifeform: !#s gcc5
asciilifeform: and i mean, all of it. no gcc5 on the box anywhere.
mike_c: that was gcc5
mod6: mike_c: I don't think it did. I set this one up like back in the spring. And I'm fairly sure it came with gcc5 and i vanquished all the bs by hand.
mod6: i think you can check in /etc/alternatives or whatever, to ensure there are no links or nothing to gcc5.
mod6: are you certain that gcc5 is vanquished from your sys?
mod6: this bug seems to pop up with gcc5 iirc.
mod6: yeah. it doesn't work with gcc5. this looks like the ncurses bug.
mike_c: but this did tons more. I'm going to go ahead and say gcc5 is no good for this (at least on out-of-the-box ubuntu)
mod6: make sure to use gcc4, i've seen problems myself with gcc5
phf: mike_c: i had it working with pretty much everything, gcc4, gcc5, clang/llvm. when i build manually i just use dependencies that whatever local package gives me, at which point make Just Works
asciilifeform: though i will point out that gnat+gcc5/6 might not in fact suffer from same horrors as cpp on same.
a111: Logged on 2017-06-06 00:42 ben_vulpes: oh christ xorg needs gcc5 now?
asciilifeform: now you might try same recipe, cum a gcc5 ban
asciilifeform: ( re gcc5 : http://btcbase.org/log/2017-06-03#1665170 ) ☝︎
ben_vulpes: oh christ xorg needs gcc5 now? ☟︎
mircea_popescu: i thought this is what we're all trying. only to discover that whatever, xorg now no longer builds without gcc5 etc.
mod6: in fact, the gcc5 thing is driving me nuts too; i've got a new notebook to replace the one with the bad 'o' key (you might remember from c3) and getting everything setup is like hair-pulling.
asciilifeform: this is what the gcc5 folks spend their time doing.
asciilifeform: on top of this, gcc5 happily removes , e.g., memset
a111: Logged on 2016-09-13 17:49 asciilifeform: even gcc5 no longer does.
a111: 6 results for "gcc5", http://btcbase.org/log-search?q=gcc5
asciilifeform: !#s gcc5
asciilifeform: because cpp11 is how folx typically end up reluctantly grunting in the stake of gcc5
asciilifeform: even gcc5 no longer does. ☟︎
asciilifeform: see also the gcc5 threads
asciilifeform: mircea_popescu: so long as it isn't gcc5, it builds.
asciilifeform: removing boost would be a worthy thing. BUT NOT if it multiplies the line count 2x, OR if it entails forcing gcc5 build
asciilifeform: http://log.bitcoin-assets.com/?date=16-01-2016#1373346 << if you have a box with gcc5, just format the hdd and start over, sanely ☝︎