log☇︎
234 entries in 0.665s
spyked: http://btcbase.org/log/2018-03-28#1790159 <-- I checked on my system using ave1's instructions and it indeed uses adacore's gcc. however: gcc uses its collect2 utility for linking (for some link-time optimization stuff -- check using gcc -v source.c), which in turn uses the *system* ld, i.e. /usr/bin/ld. that's why there's a difference in the link-time behaviour ☝︎
a111: Logged on 2018-03-28 20:41 phf: hmm, i wonder if adacore's gprbuild uses its own gcc or global one
phf: hmm, i wonder if adacore's gprbuild uses its own gcc or global one ☟︎☟︎
mod6: for what its worth, at the bottom of my paste, i've denoted that im using gcc 4.9.4 and adacore 16
phf: the issue was already reported by someone else, but at the time the suggested fix was to put a bunch of C level annotations (some combination of static inlines), which i didn't think was an adequate solution, given that i don't understand why it does or doesn't work. but ascii's explanation makes sense, though i can't reproduce the issue on any of the machines i have with adacore's gnat (freebsd, osx, debian)
diana_coman: I'm using gprbuild 2016 with gcc 4.9.4, both from adacore
spyked: http://btcbase.org/log/2018-03-01#1786626 <-- I ran it on Debian/Adacore 2016 -- system ld is version 2.29.1, and I expect Adacore uses that instead of its own, otherwise I can't explain the behaviour. I'll also give it a try on a Gentoo with same adacore. static inline should be safe from the pov of linkage, but yeah, there's a more general problem there that might benefit from a config.h/system.h or something similar. that or a ☝︎
diana_coman: when non-adacore, one easily runs into issues such as http://btcbase.org/log/2017-12-01#1745018 ☝︎
diana_coman: but again, adacore gprbuild, I can't vouch for any other version atm
diana_coman: I would say: use adacore!
mircea_popescu: diana_coman so basically a rut is shaping up here, "use gpr from adacore -- gnat / others dun actually work" ?
diana_coman: as all my non-adacore environments proved a mess
diana_coman: gprbuild from adacore works however fine to build aggregate libs as far as I can tell
mod6: anyway, on the mule, i never did get adacore running properly. this lappy is the only box i got adacore '16 running on thus far.
ave1: but also adacore docs i see: http://sandbox.mc.edu/~bennet/ada/gnat_ug/gnat_ug_4.html#SEC46
ave1: adacore 2016
asciilifeform: http server ? fwiw adacore distributes one. ( i dun like it, for same reason as apache -- it's a megatonne of gnarl . but, it does in fact work, and benefits from the language guarantees etc )
a111: Logged on 2018-01-22 14:23 caaddr: GNATMAKE 4.9.2 is the answer to the now redundant question. I'll use adacore instead. I had avoided this because it contains precompiled binaries, with no independent reproducible build certification
a111: Logged on 2018-01-22 14:22 asciilifeform: this would seem to create the unpleasant situation of having just 1 adatron. but it is not clear to me that there ever were 2. there was only adacore and broken-adacore (aka gcc-gnat)
asciilifeform: there will be a tmsr gnat; and will be based on a cleaned-up adacore gnat.
caaddr: I was able to migrate to Adacore 2016 okay, for what it's worth
a111: Logged on 2018-01-22 14:19 asciilifeform: and also i think at this point i will declare gpl-gnat to be a work of wreckers. it has zero upsides over adacore's, and a million breakages , large and small.
ave1: adacore gnat yes
ave1: Yes on restrict.adc plus it's the inline pragma that did not work for earlier FFA (adacore 2014).
a111: Logged on 2018-01-22 16:04 ave1: re: http://btcbase.org/log/2018-01-22#1773970, it seems that gcc simply lags behind and a releases version will never be updated / fixed to newer adacore releases. AdaCore 2014 also cannot build FFA from the box
ave1: nobody outside of adacore seems to work on gnat GCC, so yes single version...
a111: Logged on 2018-01-22 14:19 asciilifeform: and also i think at this point i will declare gpl-gnat to be a work of wreckers. it has zero upsides over adacore's, and a million breakages , large and small.
ave1: re: http://btcbase.org/log/2018-01-22#1773970, it seems that gcc simply lags behind and a releases version will never be updated / fixed to newer adacore releases. AdaCore 2014 also cannot build FFA from the box ☝︎☟︎
caaddr: success building Ch1 with Adacore 2016
caaddr: thanks mod6. I'm installing Adacore now
mod6: <+caaddr> http://btcbase.org/log/2017-12-02#1745440 << fwiw, in the end the version that worked for me, requiring no changes to alf's code was Adacore 2016. ☝︎
asciilifeform: caaddr: adacore's src is also posted
caaddr: GNATMAKE 4.9.2 is the answer to the now redundant question. I'll use adacore instead. I had avoided this because it contains precompiled binaries, with no independent reproducible build certification ☟︎
asciilifeform: this would seem to create the unpleasant situation of having just 1 adatron. but it is not clear to me that there ever were 2. there was only adacore and broken-adacore (aka gcc-gnat) ☟︎
diana_coman: from my own experience with adacore and with gnat, I tend to agree with asciilifeform's evaluation there ^^
asciilifeform: and also i think at this point i will declare gpl-gnat to be a work of wreckers. it has zero upsides over adacore's, and a million breakages , large and small. ☟︎☟︎
diana_coman: aha; tbh you are best off using adacore's tools
asciilifeform: No_Implicit_Conditionals is working as described on the box : https://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gnathie_ug/using_gnat_pro_features_relevant_to_high_integrity.html#controlling-implicit-conditionals-and-loops
ave1: the adacore diff also includes previous 4.9.4 patches for musl
ave1: Note that this builds adacore 2016 release (also build gprbuild)
asciilifeform: mircea_popescu: the 'gcc' fork of gnat isn't even a gnu product in the usual sense. as far as i can tell , it is made lock stock and barrel of the adacore gnat , but with some dr.mengele treatments
asciilifeform: ave1: which 2016 ? adacore's, or gpl ?
a111: Logged on 2017-11-29 01:41 asciilifeform: funnily enough adacore itself publishes a great many cut-down runtimes for various embedded boxes, e.g. https://bitbucket.org/tkoskine/embedded-arm-gnat-rts/src . BUT they are not usable: 1) there is -- quite deliberately -- not one targeting conventional userland linux 2) none of them support exception handling, which wouldn't be a problem except that ALL BOUNDS CHECKS ARE EXCEPTIONTRONIC
a111: Logged on 2018-01-07 08:39 diana_coman: http://btcbase.org/log/2018-01-07#1766177 <- I switched to adacore at some point, when I had enough of all sorts of weird trouble essentially; never had that specific type of problem though
diana_coman: http://btcbase.org/log/2018-01-07#1766177 <- I switched to adacore at some point, when I had enough of all sorts of weird trouble essentially; never had that specific type of problem though ☝︎☟︎
mod6: i use that adacore version fwiw
esthlos: sorry to be a bother asciilifeform, but still not working with adacore's gnat: http://wotpaste.cascadianhacker.com/pastes/NjSGH/?raw=true
asciilifeform: if you dont know how to magick a gentoo gcc-gnat, use adacore's
asciilifeform: diana_coman: speaking of nonemacsism, adacore's special-purpose editor, 'gps', is imho pretty decent
asciilifeform: here's the original, appreciate the horror : https://www2.adacore.com/gap-static/GNAT_Book/html/rts/a-comlin__adb.htm + https://www2.adacore.com/gap-static/GNAT_Book/html/rts/a-comlin__ads.htm
asciilifeform: i tested on both adacore and gnuist
mod6: ya. it's in the logs. i can dig it up if needed. but i believe my problem to be environmental and somehow to related to adacore.
a111: Logged on 2017-12-11 21:58 mod6: this was supposidly because im running 2015 adacore. which i can buy. but have had even less success with Adacore 2016 and 2017. not to say that I won't get the incantaiton correct at somepoint, but for now, I can't build it successfully.
mod6: this was supposidly because im running 2015 adacore. which i can buy. but have had even less success with Adacore 2016 and 2017. not to say that I won't get the incantaiton correct at somepoint, but for now, I can't build it successfully. ☟︎
a111: Logged on 2017-11-18 18:10 ben_vulpes: but the very very funny event was the script from the adacore binstaller simply fails, and instructed me to check an empty log file
asciilifeform: alternatively you can use adacore's item.
asciilifeform: i test these days on 16-gnu and 16-adacore.
asciilifeform: there is a mode ( see also log ) where it doesn't insert anything, that is used traditionally to compile gnat itself. but there it hard-enforces adacore's weird style scheme, and cannot be forced not to. i'ma have to patch.
asciilifeform: which means that none of my code even builds, because gnat then insists on adacore's idiotic massive-extra-spaces-everywhere stylistics.
asciilifeform: the docs ( https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/building_executable_programs_with_gnat.html ) but gnu's agree give us:
asciilifeform: funnily enough adacore itself publishes a great many cut-down runtimes for various embedded boxes, e.g. https://bitbucket.org/tkoskine/embedded-arm-gnat-rts/src . BUT they are not usable: 1) there is -- quite deliberately -- not one targeting conventional userland linux 2) none of them support exception handling, which wouldn't be a problem except that ALL BOUNDS CHECKS ARE EXCEPTIONTRONIC ☟︎
a111: Logged on 2017-11-27 20:42 asciilifeform: i'd naively expect that adacore's item would be the satanic one, and gcc's fork -- the functional. but so far in no case was this the finding.
asciilifeform: ( gnu-gnat or adacore-gnat people )
mod6: and adacore's is supposed to be canonical im guessing?
a111: Logged on 2017-11-27 20:40 asciilifeform: currently asciilifeform is barfing over the fact that adacore's gnat is happy to build static 'independent library' .a while gpl gcc's gnat barfs
asciilifeform: i'd naively expect that adacore's item would be the satanic one, and gcc's fork -- the functional. but so far in no case was this the finding. ☟︎
asciilifeform: currently asciilifeform is barfing over the fact that adacore's gnat is happy to build static 'independent library' .a while gpl gcc's gnat barfs ☟︎
asciilifeform: ( or adacore's gnat )
asciilifeform: whaack: i wrote the thing back when i was mostly using adacore's gnat
a111: Logged on 2017-06-06 20:38 asciilifeform: diana_coman: the example was written on a box with adacore's gnat; the stock gnu one is stricter, doesn't permit Foo'Image -- instead you gotta FooTypeName'Image(Foo)
ben_vulpes: but the very very funny event was the script from the adacore binstaller simply fails, and instructed me to check an empty log file ☟︎
ben_vulpes: tried both binturd from libre.adacore and a portage ebuild
asciilifeform: see also the pertinent ARM , 4.3.3 'array aggregates', https://www2.adacore.com/gap-static/GNAT_Book/html/aarm/AA-4-3-3.html#I2421 .
mircea_popescu: meanwhile in useless tards, https://www.adacore.com/developers/development-log/NF-503-D817-011-gnat
asciilifeform: because adacore's mmap lib is a massive pile of shit ( e.g. includes winblowzisms )
asciilifeform: mod6: http://www.adacore.com/adaanswers/gems/gem-54/
asciilifeform: http://www.adacore.com/adaanswers/gems/gem-142-exceptions/ << moar likbez
ave1: asciilifeform: for http://btcbase.org/log/2017-07-21#1688362, it looks like you are building with adacore 2016 edition, could you try with the 2015 edition (no need to do a real install, just unpack it and set path to the bin dir will be enough) ☝︎
ave1: it will build adacore's gpl 2015 by default, cd into dir, run ./ada-build.sh /absolute/build/dir
a111: Logged on 2017-06-06 20:56 diana_coman: neah, it says it can't even see it then; will try another time with the adacore 4.9
diana_coman: asciilifeform, fwiw re http://btcbase.org/log/2017-06-06#1666713 <- finally got around to try it and I can confirm it works perfectly fine on gnat 2016 from adacore, gcc 4.9.4 ☝︎
a111: Logged on 2017-07-19 12:54 ave1: (but the 4.9 gcc from adacore does not match any 4.9.* release from FSF)
asciilifeform: mircea_popescu: so far it seems to be that adacore's gnat actually implements the standard; while fsf is a bit moth-eaten
ave1: p.s I already have a musl build for x86_64 (based on musl_cross) (works on adacore stuff and gcc-4.9.4), but is needs some more work
ave1: Go here: http://libre.adacore.com/download
shinohai: ave1: Can you link me to the adacore sources that worked for you?
ave1: and gcc 4.9.4 does so, but the adacore code has problems
ave1: (but the 4.9 gcc from adacore does not match any 4.9.* release from FSF) ☟︎
ave1: I can build a gnat using the sources from adacore and all is fine
ave1: Turns out the version of gnat in gcc 4.9.* is based on GNAT GPL 2014 (from adacore)
mod6: ok, so i dropped on a binary install of adacore onto my gentoo environment here just to test...
mod6: also, above, I pasted the wrong link to adacore, here's the one that I was given to get the adacore source: http://libre.adacore.com/download/configurations
mod6: im more referring to the massive tarball that you get from adacore
mod6: <+asciilifeform> mod6: the official adacore gnat installs in 3minutes, but with obvious caveat (you live with binarolade) << yeah, i see they do have bins, but was going to custom handroll my own, to not only get one sanely built for my own environment, but will also allow me to set whatever ./configure flags I might need for optimizations.
asciilifeform: mod6: the official adacore gnat installs in 3minutes, but with obvious caveat (you live with binarolade)
mod6: shinohai, I think, figured out a way to do this, and pointed me at: http://www.adacore.com/products , but I haven't dug into it yet myself.
asciilifeform: fwiw i have a box with the adacore bin gnat, everything worx great even there
mod6: My thinking is that, if i need to be able to use all the switches ad denoted in your makefile (since my mine doesn't seem to allow for that), I may need the adacore configuration.
mod6: <+asciilifeform> mod6: not the problem. my thing builds on both adacore's and trad gnu gnat. << yeah not sure what the problem is. it's a binary installation of gnat via apt-get, so that, i'm sure is part of the issue. however, it works better than the first ada configuration that I had, which, didn't work at all.
asciilifeform: mod6: not the problem. my thing builds on both adacore's and trad gnu gnat.