log
229 entries in 0.425s
bvt: asciilifeform: i have built ave1gnat with mipsel-sf support with a small patch (http://bvt-trace.net/src/gcc-4.9.adacore2016-4-mipsel.diff) -- adacore has snipped those files from their source distribution.
a111: Logged on 2019-02-15 17:45 diana_coman: http://btcbase.org/log/2019-02-15#1896926 -> this failed precisely in the same way; need to get to the bottom of it really because Adacore's gnat otherwise IS compiled with sjlj so wtf
ave1: going is slow, last try resulted in a crash with a text to contact adacore
mod6: For completeness, this is what happens when you try to install AdaCore 2016 (binaries) on Cuntoo (keep in mind that the install actually does place the binaries in the expected places...): http://p.bvulpes.com/pastes/vX16f/?raw=true ♖︎
mod6: so I never was able to build the ave1 musltronic tools on cuntoo, because no working gnat, I just bundled them up after I built them on a gentoo machine that had a working AdaCore 2016.
mod6: To make this work properly, I built all of the ave1 musltronic tools on a gentoo instance with a 2016 AdaCore GNAT, then bundled up all of the binaries myself, and placed 'em on mod6.net for testing purposes.
bvt: http://btcbase.org/log/2019-04-22#1909279 << you can't use adacore's gnat to bootstrap ave1gnat on musltronic systems, but http://btcbase.org/log/2018-05-15#1813753 works for that purpose; ☝︎☝︎
diana_coman: o.O so you're saying that apparently gprbuild --RTS=sjlj on adacore's gnat STILL pulls in some zcxism??
diana_coman: asciilifeform, for completeness, adacore's gnat with --rts=sjlj throws only one undefined reference rather than a bunch; here's the winner: undefined reference to symbol '_Unwind_Resume@@GCC_3.0'
diana_coman: in good news, it seems that the static-only ave1-gnat builds itself fine (with the tarballs ofc so ultimately still relying on the corpse but at least that's frozen and the whole thing is NOT relying anymore on a deployed adacore)
a111: Logged on 2019-02-28 20:49 bvt: also, at least for vxworks, adacore for certified profiles supports only sjlj, while using zcx for non-certified use-cases
bvt: also, at least for vxworks, adacore for certified profiles supports only sjlj, while using zcx for non-certified use-cases ☟︎
asciilifeform: https://www.adacore.com/products/certification-materials etc
asciilifeform: mircea_popescu: adacorpse appears to be inbiz, but hard to say when last did anyffin useful ( see e.g. https://www.adacore.com/press )
mircea_popescu: coincidentally : is anyone from the adacore/gnat/gnarl/whatever days still breathing even ? or 100% bolix situation, "documents at warehouse, i am machinist in charge" ?
diana_coman: update re builds: it built fine with --enable-sjlj-exceptions in place, checked it in the log and yes, it's set; but the result still seems to be build ada code with zcx in fact (i.e. my test code with tasks is STILL hung waiting for them to abort) and if I specify --rts=sjlj to gprbuild it complains that there is no native compiler for ada and so can't do anything; ftr I compared the dirs of my adacore install and it has this specific dir
a111: Logged on 2019-02-15 16:12 diana_coman: hm, full replica might require I upload somewhere the tarballs too since at least 1 link was broken ; anyways, it's with http://ave1.org/2018/building-gnat-on-musl-now-always-static/ + taken out the download script for ada2016 because broken link + added GCC_CONFFLAGS="--enable-sjlj-exceptions" to extraconfig.sh ; set path to point to existing and working adacore 2016 gnat + put all tarballs in their place
a111: Logged on 2019-02-15 17:45 diana_coman: http://btcbase.org/log/2019-02-15#1896926 -> this failed precisely in the same way; need to get to the bottom of it really because Adacore's gnat otherwise IS compiled with sjlj so wtf
diana_coman: because no, the one installed on the machine and used for the scripts is adacore's
diana_coman: http://btcbase.org/log/2019-02-15#1896926 -> this failed precisely in the same way; need to get to the bottom of it really because Adacore's gnat otherwise IS compiled with sjlj so wtf ☝︎☟︎☟︎
diana_coman: hm, full replica might require I upload somewhere the tarballs too since at least 1 link was broken ; anyways, it's with http://ave1.org/2018/building-gnat-on-musl-now-always-static/ + taken out the download script for ada2016 because broken link + added GCC_CONFFLAGS="--enable-sjlj-exceptions" to extraconfig.sh ; set path to point to existing and working adacore 2016 gnat + put all tarballs in their place ☟︎
diana_coman: all those tests are on Adacore's 2016 gnat, yes
diana_coman: I guess until now I always built ave1's gnat on a machine that had adacore's gnat installed with all the paths to libs like that quite standard so possibly that's why it never failed
diana_coman: that's how it sounds from adacore's link; then again the description of the pragma in gnat ref manual is "it has the effect of deferring aborts for the sequence of statements (but not for the declarations or handlers, if any, associated with this statement sequence).
diana_coman: from the horse's mouth at https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/platform_specific_information.html : "the zcx run-time does not support asynchronous abort of tasks (abort and select-then-abort constructs) and will instead implement abort by polling points in the runtime. You can add additional polling points explicitly if needed in your application via pragma Abort_Defer."
ave1: trinque, http://btcbase.org/log/2019-02-03#1891961, I've build it with itself (i.e. musl). But the ultimate start has always been the gcc version from AdaCore. I could not get it to work with an FSF start. ☝︎
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)