log
203 entries in 0.433s
lobbes: http://btcbase.org/log/2018-12-04#1878321 << ftr this was indeed an adacore gnat >=2017 (see thread), though I'm not sure about the libc. ☝︎
a111: Logged on 2018-12-03 22:24 bvt: lobbes: i am also interested in learning which gnat version/type and vtools leaf was used, and seeing strace output; i thought this error can happen only on adacore gnat >=2017 with a strict libc (which rejects 3-character template)
lobbes: diana_coman, bvt: this was indeed a newer adacore (from May 2018) https://www.adacore.com/download. I'm going to look into the tempfile thread alf mentioned. may very well be the same issue
bvt: lobbes: i am also interested in learning which gnat version/type and vtools leaf was used, and seeing strace output; i thought this error can happen only on adacore gnat >=2017 with a strict libc (which rejects 3-character template)
asciilifeform: granted ave1's gnat still has 'miles to go' in some aspects, gotta be de-autoconf'd ( asciilifeform aint ever signing ANYTHING with autoconfolade in it ) and genesis'd. but it worx a++, is portable (to arm, currently) and is frozen, which is good bit moar than can be said for adacore's thing
a111: Logged on 2018-12-03 20:52 lobbes: Since this was my first time using vtools, I used diana's "starter v" with the build.sh. Script ran fine, and vtools such as ksum are working. I installed GNAT from https://www.adacore.com/download (the x86-64 GNU Linux). I'm on my debian box, gcc version 4.9.2
lobbes: Since this was my first time using vtools, I used diana's "starter v" with the build.sh. Script ran fine, and vtools such as ksum are working. I installed GNAT from https://www.adacore.com/download (the x86-64 GNU Linux). I'm on my debian box, gcc version 4.9.2
bvt: i.e. https://docs.adacore.com/gnat_rm-docs/html/gnat_rm/gnat_rm/standard_and_implementation_defined_restrictions.html#partition-wide-restrictions
bvt: but yes, it is adacore -- not the default sad gcc implementation
diana_coman: bvt, is that adacore's gnat?
a111: Logged on 2018-10-24 15:25 asciilifeform: incidentally, https://www.adacore.com/gems/gem-59 apparently exists, tho i confess that i really dislike the idea of automatic converters for coad
asciilifeform: incidentally, https://www.adacore.com/gems/gem-59 apparently exists, tho i confess that i really dislike the idea of automatic converters for coad
a111: Logged on 2018-10-05 16:21 asciilifeform: diana_coman: https://www2.adacore.com/gap-static/GNAT_Book/html/rts/s-crc32__adb.htm << pretty simple, you can even lift and civilize
phf: i've used a variety, including the two you mentioned. ave1's, adacore 2016 and 2018 on linux and mac
bvt: did you use ave1's gnat or the adacore-provided distro? My understanding is that it should work with both, taking 2 different code paths, and fail only with gnat17.
asciilifeform: diana_coman: https://www2.adacore.com/gap-static/GNAT_Book/html/rts/s-crc32__adb.htm << pretty simple, you can even lift and civilize
phf: actually, that is what's going on! but i'm not sure how it got that way, because i've both tested adacore's gnat ahead of time, and also had it building things. something must've gotten clobbered
phf: by then adacore gnat gcc already managed to compile a whole bunch of stuff
ave1: to debug it, just try to compile a basic C hello world with the AdaCore gcc (and also with the system gcc, with -v so that it shows you the paths)
ave1: phf, your error is in the AdaCore gnat gcc (gcc -version shows these boron.a directories)
asciilifeform: errywhere i tried it, i built 1st stage on adacore's gnat, which iirc is 4.9.4
asciilifeform: phf: you gotta unset the typical gnat includes envir , e.g. here's asciilifeform's from 1 particular box, http://p.bvulpes.com/pastes/pUeES/?raw=true ( already has an ave1 gnat ,prior to that pointed to adacore's thing )
ave1: AdaCore has python scripts that copy stuff for this.
diana_coman: asciilifeform, ah, I forgot to mention it explicitly but yes, my tests include ave1's gnat as well as adacore's gnat; this is pretty much for any ada code I test
diana_coman: now I need to read at least https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/inline_assembler.html
ave1: this builds with the musl gnat, the binary from adacore and the latests zfp.
diana_coman: while initially I considered using this thin layer, on a deeper look at it, I don't like it; here is the code of it: https://www2.adacore.com/gap-static/GNAT_Book/html/rts/g-socthi__ads.htm and https://www2.adacore.com/gap-static/GNAT_Book/html/rts/g-socthi__adb.htm
asciilifeform: ( the appeal of 'own gnatsockets' is similar to that of what i did with mmap : adacore's implementation is quite obese on acct of handling winblowz and other broken os )
asciilifeform: https://www.adacore.com/gems/gem-140-bridging-the-endianness-gap << possibly useful item re endianism
asciilifeform: ave1: afaik adacore already distributed a 32bit one, might want to look to see what it was made of
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. ☝︎