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
@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
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
@catoutofbed why does a.out not list a dependency on ld-linux-x86-64.so.2?
@catoutofbed (also lol on my system ldd is a static binary. seems appropriate)
@iliana it's uh
it's a bash script on here?????
@catoutofbed oh christ it is a shell script
I always assumed...
@iliana
they're pretty bad
@catoutofbed @iliana ban computers
@catoutofbed
# This is the `ldd' command, which lists what shared libraries are
# used by given dynamically-linked executables. It works by invoking the
# run-time dynamic linker as a command and setting the environment
# variable LD_TRACE_LOADED_OBJECTS to a non-empty value.
I hate computers