PeterL: whaack: looks like we were peered up to the 20th, seems we lost the connection somehow?
signpost: billymg: might need to fiddle with LD_LIBRARY_PATH depending on what you told gnat was sysroot during build
signpost typically uses static linking to avoid this bullshit.
signpost: here's my item's "ebuild" for gnat, if helpful http://paste.deedbot.org/?id=I-Na
signpost: and env vars for what my equiv of "emerge" would set http://paste.deedbot.org/?id=uEkl
billymg: signpost: i don't remember specifying a sysroot when installing gnat. i used the 2016 bin from asciilifeform's mirror, then just followed the steps in the ./doinstall script. it asked where i wanted to install gnat and for that i left it as the default (/usr/gnat)
signpost: not familiar with that script, sorry
billymg: signpost: ah, that gets me somewhere at least. i can try reinstalling it another way
billymg: if i go to reinstall just want to be sure i'm at least using the right tarball
signpost: yep, that one's the starting point I've used.
billymg: ok, i'll look at it more closely and see if i can figure it out
signpost: if you don't get errors during build about language constructs the compiler doesn't know, it's most likely a matter of the build making assumptions about your build environment that don't hold on another machine.
signpost has spent most of his time backing these assumptions out.
signpost: say, environment variables leaking in that are different between machines
signpost: env -i is useful there as long as you know what env vars you need to preserve
signpost: can do things like env -i PATH="$PATH sh which would pull just the outer shell's path into a new subshell