So I could make python script, which passes assembler code to 'as' stdin and get's resulting binary through 'ld' stdout.
Update:
I have already tried '-o /dev/stdout', but this isn't work:
as -o /dev/stdout test.s
test.s: Assembler messages:
test.s: Fatal error: can't write /dev/stdout: Illegal seek
test.s: Fatal error: can't close /dev/stdout: Illegal seek
Update II:
why would you want to do such a thing?
want to create python binding for gsasl. to dynamically generate machine code to use it as callbacks which calls python callables somehow (for gsasl_callback_set). using stdout instead of temporary files for greater security and performance. just one of My crazy ideas.. since making callback with SWIG is not so easy.. currently trying to play with Vala and Gir,, maybe it will be more universal way.. and there is reasons why I don't want to use cython.
Those two tools' output can't be redirected. The hackish way to do so, is write a launcher which starts as or ld and after they completion reads contents of already made file pointed by -o option into stdout (or some other way).
To work with callbacks in scripting languages, there are libffi, which is already used by Cython and many other language's meanings to interact with C/C++ code callbacks.
The great deal here present's so called "user data" parameter in C/C++ target callback, so other language's (Python in this case) object (probably function or method) pointer or descriptor could be passed with callback to preserve context. Gsasl's callback mechanisms do not have such "user data" parameter, and good fashioned binding to some class instance is not possible, so tracking callback context will require creating and using global variable in python, so it is better to find pure python implementation of something, than using globals or singletons.