log
173 entries in 0.417s
phf: (^ POSIX shell for windows written in Ada, presumably for adacore build toolchain)
phf: (in related lulz, https://github.com/AdaCore/gsh)
asciilifeform: https://docs.adacore.com/gnat_ugx-docs/html/gnat_ugx/gnat_ugx/the_stacks.html#the-secondary-stack << the horse's mouth, re details.
phf: unlike tmsr, adacore people are not attempting to also _build_ on a spaceprobe ;)
ave1: also, for the adacore minimal images look at: https://github.com/AdaCore/bb-runtimes
asciilifeform: phf: adacore actually distributes a compiler like this. but it is commercialware, and i've never seen it.
phf: ave1, asciilifeform or other ada specialists, how did you bootstrap a gnat on aarch64? is there some binary that's floating around (because adacore doesn't seem to have linux-aarch64 build) or is it bootstrapped using a cross compiler on a x86 linux?
asciilifeform: in other interesting rtfm's, https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/building_executable_programs_with_gnat.html#style-checking << it is possible to trigger enforcement of, e.g., max line width, absence of winblowz linefeeds, tabs, etc
asciilifeform: ( https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/gnat_and_program_execution.html#performing-dimensionality-analysis-in-gnat for the interested gnatologist )
asciilifeform: the next step will be to get the dep tarball links the hell off adacore's www, and onto our own cuntoo mirror.
spyked: asciilifeform, gcc --version returns adacore's (2016) 4.9.4
a111: Logged on 2018-05-15 21:28 asciilifeform: diana_coman: steps to replicate: 0) on a machine WITH A WORKING GNAT (e.g. adacore's , and it must be in your path already ) 1 ) download the tarball from http://ave1.org/2018/building-gnat-on-musl-now-with-partial-and-parallel-build-support 2) unpack tarball ada-musl-cross-2018-05-15.tgz , go to the dir 3) mkdir bin << this is where the built binariola will live 4) ./build-ada.sh /home/foo/temp/ada/ada-musl-cross-2018-05-15/bin
asciilifeform: ( in shot 1, it used the adacore gnat installed in first step of procedure http://btcbase.org/log/2018-05-15#1813719 )☝︎
diana_coman: ah, free bla bla; no, I meant with the output of ave1's script (even if at the very root one used adacore's, once upon a time, fine); basically what I was trying to do yesterday on rockchip
asciilifeform: i assume 'non-adacore' implied the former ?
asciilifeform: diana_coman: there are 2 known gnat codebase 'forks' , 'fsf'/gnu and adacore
diana_coman: I'd really like to have a clear and tested way to bootstrap with non-adacore gnat though
diana_coman: ave1, happy to say that your script worked perfectly fine on x86_64 with Adacore's 2016 gnat!
ave1: btw, I've not tried running the scripts with the generated native compilers, I always start with the binary from adacore
asciilifeform: this is fine, so long as it is understood that it is not necessarily 'cleaner' than adacore's
diana_coman: asciilifeform, I really get that but onth if I have to get a bin I'd much, much rather get one from you than from adacore
diana_coman: I thought adacore had a gnat for arm too?
asciilifeform: diana_coman: steps to replicate: 0) on a machine WITH A WORKING GNAT (e.g. adacore's , and it must be in your path already ) 1 ) download the tarball from http://ave1.org/2018/building-gnat-on-musl-now-with-partial-and-parallel-build-support 2) unpack tarball ada-musl-cross-2018-05-15.tgz , go to the dir 3) mkdir bin << this is where the built binariola will live 4) ./build-ada.sh /home/foo/temp/ada/ada-musl-cross-2018-05-15/bin
ave1: I've run on multiple systems (ubuntu and redhat), procedure has been to unpack the adacore binary file, set path and go (no ADA_*_PATH)
ave1: asciilifeform: the exact same line in my build output shows almost the same -I directories, except all end with adalib/../adainclude, that last part '../adainclude' seems to be missing on your side. I will start a rebuild with some extra logging on that line. I will get back to it tomorrow. In the mean time, I have only set the path to the adacore gnat tools and I do not have any other GNAT* flags or CFLAGS or LDFLAGS etc. etc.
ave1: o sorry, no not musltronic, the adacore one will work fine
asciilifeform: right, but ave1 did you actually get the complete equivalent-to-binary-kit-from-adacore-complete-with-gprbuild-etc made ?
ave1: you'll need gnat2016 from AdaCore on an intel 64bit machine, and that should be all (except for a shell tar, curl etc)
ave1: I found out that GNAT 2016 has some support for arm 64bit, but for android and ios and not for linux. So I had to do some small patching (I also looked at the 2017 version and I still could not find plain linux support in the adacore gnat)
diana_coman: did anyone publish a compilation recipe for adacore's gnat on republican gentoo? searching the logs returned only various troubles and otherwise mod6's attempt as most recent from what I can tell: http://btcbase.org/log/2017-07-17#1685215☝︎
a111: Logged on 2018-04-06 18:37 ave1: btw, turns out AdaCore have implemented support for crapple IOS (arm 64 + macho) in their gcc, this cannot be found in fsf gcc's. But needs #ifs and #ifdefs, one line was #ifdef MACHO_TARGET, but should have been #if.
ave1: asciilifeform, yes I know, I've not tried to separate AdaCore's ada from AdaCore's gcc backend (to FSF gcc backend). AdaCore's gcc backend has significant canges from FSF. As this would be an interesting experiment, I will put it on the list (other thing to do, is put Ada 2017 on top of gcc 4.9.4 instead of 7.x)
ave1: btw, turns out AdaCore have implemented support for crapple IOS (arm 64 + macho) in their gcc, this cannot be found in fsf gcc's. But needs #ifs and #ifdefs, one line was #ifdef MACHO_TARGET, but should have been #if.
mircea_popescu: adacore is perhaps the closest contemporary approximation ; why not pay them a little for their pompous if economically dysfunctional "moneymaker" and then brazenly ask them to help you ruin the whole thing ?
mircea_popescu: anyway, im pretty sure the adacore people were fucking around with arm64 at some point. maybe asc gingold or someone ?
mircea_popescu: listen. the zynq is a 64 board ; and it's in the adacore's list of somewhat supported packages.
mircea_popescu: didn't adacore itself release a bare arm gnat ?
asciilifeform: the inexistence of a binary arm64 adacore gnat distro
a111: Logged on 2018-03-28 20:41 phf: hmm, i wonder if adacore's gprbuild uses its own gcc or global one
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