Paul Edwards wrote: > > What is the problem with having GCC itself invoke the linker, just like > > it does on other platforms? > > 1. That requires extensions to the C90 standard. The behaviour of > system() is undefined, much less even the existence of fork() etc. > > 2. The attempt to add functionality to system() in MVS has made > leaps and bounds, but has not reached the stage of being able > to detect if the SYSPRINT DCB is already open so it knows not > to reopen it, and close it, stuffing up the caller. > > 3. MVS compilers don't normally invoke the linker. That's always > a separate step. GCCMVS is an MVS compiler also. It would > be normal to generate object code though. But the compiler > normally generates the object code, rather than invoking the > assembler. In any case, the facility to allocate temporary > datasets for HLASM and deciding what space parameters > should be used etc etc has not yet been determined, and is > unwieldy regardless, and the functionality doesn't exist yet > anyway, and may be years away still, if it even makes sense.
I cannot really comment on what would be desirable behaviour for MVS ... Just as an implementation note, while it is true that the GCC compiler driver needs to be able to execute other processes (preprocessor, compiler, assembler, linker) as sub-tasks, it does not require the full POSIX system/fork/exec functionality to do so. GCC relies on the libiberty "pex" family of routines, which are much more narrow in scope, and have in fact been ported to several non-UNIX systems, including even MS-DOS. Providing a port of "pex" to MVS should be much easier that porting a full Unix "system" or "fork" feature. B.t.w. if you cannot execute sub-tasks at all, how does the MVS GCC invoke the preprocessor (I think this was still a separate process in 3.2) and the core compiler (cc1) from the compiler driver? Do you even have a separate compiler driver? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
