hi i produced an executable that when i try to run it bash claims it's not real

@catoutofbed that's probably not bash claiming it then

multiple things can return the same errno

@iliana

@catoutofbed run ldd on it

@iliana
what a badly named error then

@iliana
nope, i fixed that and it's a completely different error that's making bash error out

@catoutofbed errno(3) is a global variable that contains the last error, and the exec(3) family of functions returns errors like that

so *anything* in exec's path returning ENOENT causes bash to provide that error message

@catoutofbed you probably already knew that actually. hrm.

@catoutofbed anyway. how does ldd look now?

@iliana
https://unix.stackexchange.com/questions/13391/getting-not-found-message-when-running-a-32-bit-binary-on-a-64-bit-system/13409#13409

this is not good behavior >.<

@iliana
it seems to be finding the libraries and i *should* be able to run x86_64 executables

@catoutofbed given that ldd is probably an x86_64 executable, I would believe you

now run ldd on liblib.so

@iliana

@catoutofbed why does a.out not list a dependency on ld-linux-x86-64.so.2?

@iliana
goooooood question

@catoutofbed what happens if you run

$ /usr/lib64/ld-linux-x86-64.so.2 ./a.out

@iliana segfault
which is probably on my end so i think we're running properly

@iliana so now the question of what the hell is ld doing that causes it to not link that

@iliana
so it gets weirder?
i tried invoking rustc with --crate-type=cdylib instead of dylib
now it's linking what appears to be correctly and yet????

@catoutofbed does ./a.out define _start?