Klaus Grue wrote: > Question 1. The dlopen(), dlclose(), dlsym(), and dlerror() functions from > libdl provide a library interface to the dynamic loader. Does there exist > a similar library interface to gcc so that one can avoid the > pipe-fork-execve-wait overhead of running gcc in a separate process? No, nothing like that exists. The closest thing is probably the incremental compiler project, currently under development on a branch. The goal is to turn gcc into a long-running daemon/server process to avoid the startup cost of having to invoke gcc for each object, and to be able to re-use the results of parsing common header files, potentially with multiple threads. But there's no exported C API for this as far as I know, it would still continue to interface with the normal gcc command line invocation. > Question 2. The implementation of source2dl() above uses a temporary file > named dl.so for the shared object produced by gcc and read by dlopen. It > would be convenient if communication from gcc to dlopen could go via a > pipe. Does anyone know a way to tell gcc to write the shared object to > stdout? Well first, gcc doesn't write to the shared object file. The only thing gcc ever writes is assembly to an .s file, or in this case since you used -pipe, that goes over a pipe to the assembler which writes to an .o file, which is a temporary file somewhere in $TMP since you aren't using -c. Then gcc invokes collect2, which in turn invokes ld, which is what actually reads the .o file and writes the .so file. ld cannot write to a pipe, it must write to a file. Even if it could, you still have a temporary file that is created and deleted in the form of the .o, so I don't think it's ever going to be possible to do this without creating a file. The toolchain just wasn't designed to be used like that. > Question 3. Following up on Question 2, does anyone know a way to tell > glopen to read the shared object from stdin? dlopen has to mmap() the file into memory to execute it, so there has to be an underlying file somewhere. I don't think you can get around that. You could of course create the file in a tmpfs filesystem so that it's all in memory, and unlink it after it has been dlopened so that it's not accessible through any directory entry. If you do this then it will automatically be reclaimed by the filesystem whenever the last open handle to it closes, i.e. the process that has it mapped terminates. > I hope someone listening at gcc-help can help on these questions or give > pointers to information or give suggestions for alternative ways of doing > dynamic compilation. I don't see what's so bad about using files. unlinking an open file is the standard technique when you have a temporary file that you want to not be accessible to other processes and that you want to be automatically cleaned up by the operating system when it's no longer in use. Brian
