build fails on musl-libc based linux systems (for example alpine, void, sabotage)

[rofl0r]

dynamorio-release_6_1_1/core/unix/os.c: In function 'handle_close_pre':
dynamorio-release_6_1_1/core/unix/os.c:5620:30: error: dereferencing pointer to incomplete type
dynamorio-release_6_1_1/core/unix/os.c:5636:30: error: dereferencing pointer to incomplete type
dynamorio-release_6_1_1/core/unix/os.c:5652:29: error: dereferencing pointer to incomplete type
make[2]: *** [core/CMakeFiles/dynamorio.dir/unix/os.c.o] Error 1

the code in question is

            /* update the privately loaded libc's stdout _fileno. */
            (*privmod_stdout)->STDFILE_FILENO = our_stdout;                     


            /* update the privately loaded libc's stderr _fileno. */            
            (*privmod_stderr)->STDFILE_FILENO = our_stderr;


            /* update the privately loaded libc's stdout _fileno. */            
            (*privmod_stdin)->STDFILE_FILENO = our_stdin;

FILE is an opaque type and it's illegal to make assumptions about or access the underlying struct from non-libc code.
I'm currently talking with musl's author if there's a portable solution.
the code in question was introduced to fix #261

[rofl0r]

a possible solution could be to use separate fds for the logging purposes rather than hijacking the ones of the app.

[derekbruening]

Unfortunately it is sometimes unavoidable to break abstractions and take "illegal" steps for low-level systems like DR, in this case to load a private copy of libc and isolate it from the app's copy.

I don't think tools are willing to give up printing directly to stdout or stderr: interleaving tool output with app output can be very valuable for a tool user.

[rofl0r]

can you elaborate about "load a private copy of libc and isolate it from the app's copy" ?
i think this is highly problematic especially with regard to the global state of the memory allocator.

[derekbruening]

Malloc & co. are redirected to DR's own allocator. See http://dynamorio.org/docs/using.html#sec_extlibs

[egrimley]

Presumably there is no portable way of doing this redirection of a stream. There's fdopen() for converting a file descriptor into a stream, and there's freopen() for redirecting an existing stream to a new file, but there doesn't seem to be a way of redirecting an existing stream to an existing stream or file descriptor.

[rofl0r]

in that case may i suggest that this feature only gets activated if the non-portable prerequisites exist ? for example by doing a configure check.