in case of an error condition, both start_chain() and chain_step()
were closing the fd to be acted upon, without setting it to -1,
and the function calling them would close them again.
this could affect multi-threaded applications that opened new fds
between the first and the second close, invalidating those fds
in the targeted app.
patch loosely based on report and PR by @jhfrontz.
closes#542
closes#497
in order to make this work, also the change in 2d265582a2
was required; otherwise the sendto() call from rdns lookup would
cause the init code to be called from within the init code and
ultimately hanging on pthread_once().
before we started to use the gcc constructor attribute to load our
initialization code, each function hook used to check whether the
initialization was already done, and if not, do it at that point.
this workaround is quite ugly, and creates a circular reference
if the startup code calls any of the hooked functions.
now we only do the lazy init if the compiler used is not GCC
compatible.
according to research done by @malash, the proxychains4 binary
itself isn't allowed to use system-internal arm64e mode; but
it's possible to add it as a 3rd architecture to the shared
library (.dylib), and then even inject it into system binaries
like /usr/bin/curl, which didn't work since the introduction
of SIP.
therefore, we now create the dylib with all 3 archs, but the
launcher only with arm64 and x86_64.
closes#453
even though the preload library was built correctly, the LDFLAGS set
weren't passed to the main proxychains4 binary, resulting in link
errors against the fat object files.
closes#452
