tmsr - Search: adacore

jfw: Besides proprietary GPU drivers there are other "traditional Linux" things not likely to run on musl with any amount of futzing, such as compiled non-static binaries (proprietary apps, the Adacore GNAT distribution) and "enterprisey" thinks like authentication plugins; I can't speak to whether we should care about these.

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

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: 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

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: 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 ☟︎

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.

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

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)

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 )

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

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: ave1: afaik adacore already distributed a 32bit one, might want to look to see what it was made of

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: the next step will be to get the dep tarball links the hell off adacore's www, and onto our own cuntoo mirror.

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

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

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.

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.

a111: Logged on 2018-03-28 20:41 phf: hmm, i wonder if adacore's gprbuild uses its own gcc or global one