i370 port - constructing compile script

[Paul Edwards]

>> The failure (on 3.4.6, but not on 3.2.3) is that after the successful
>> build, when I do an xgcc -S, it produces the assembler file, and then 
>> hangs.  I traced this to gcc.c which was in a loop doing this:
>> 
>> pid = pwait (commands[i].pid, &status, 0);
>> 
>> getting a return of 0 all the time, while the process (cc1) that it is
>> waiting on is showing up as being <defunct>.
>> 
>> Not sure what that is about.  I have gcc 3.2.3 working without that
>> problem, so I'll spend some time comparing how the two pexecutes
>> work differently.
> 
> Huh.  I've never seen this before.  Is this with your patches to
> generate a "single executable" or without?

My patches are applied, but shouldn't be activated, because
I haven't defined SINGLE_EXECUTABLE.

I could try taking it back to raw 3.4.6 though and see if that has
the same problem.

> For the cross-compiler,
> you shouldn't need any of the MVS host-specific patches ...

My target is new basically.  It's closest to mvsdignus, which
was used as a starting point, but it has evolved.  :-)

>> In the meantime, I have a question.  You said above that I have to
>> point sysroot to the MVS libraries and headers.  What libraries?
>> And why, at the point of building a cross-compiler, do I need any
>> of those things?  The normal way I build a cross-compiler I just
>> do the above configure without prefix or with-sysroot, and it
>> builds an xgcc executable as expected, using the Linux headers,
>> as expected.
>> 
>> I would certainly like an option to force it to use my C90-only
>> Linux headers and my C90-only libraries, but that should be
>> strictly optional, and if I did do that, I would expect to see
>> configure saying things like "no you don't have fork, or getrusage,
>> or sys/types" etc etc.
>> 
>> I think I am still failing to understand some major aspect of the
>> build process.
> 
> Maybe the confusion is about what "sysroot" for a cross-compiler
> means.  The libraries and headers in the sysroot are *not* used
> to build the compiler itself.  You need to specify the sysroot
> location at build time of the compiler only so that this location
> can be compiled into the gcc/cc1 binaries.  Once you later *use*
> the resulting cross-compiler, this cross-compiler will refer to
> the sysroot location for standard headers and libraries.
> 
> That is to say, if you build a cross-compiler with
>    --prefix=/home/gccmvs/cross
>    --sysroot=/home/gccmvs/sysroot
>    --target=i370-mvs
> the result of the build process ("make" and then "make install")
> will be a cross-compiler in /home/gccmvs/cross/bin/i370-mvs-gcc
> (and additional files in /home/gccmvs/cross/lib/gcc/...).

Ok, that's a new concept to me.  Thanks.

> Note that the build process of the compiler itself will refer to
> the host's default headers in /usr/include and libraries in
> /usr/lib.
>
> However, once you *run* this i370-mvs-gcc, and it processes a source
> file using #include <stdio.h>, the compiler will search the directory
> /home/gccmvs/sysroot/include for the stdio.h header file, and it will
> invoke the cross-linker passing /home/gccmvs/sysroot/lib as the 
> location to search for standard libraries like libc.  (Note that the
> names of such standard libraries, if any, are defined by the MVS
> target definitions, in particular the setting of target macros like
> LIB_SPEC in your target header files in config/i370/*.h.)

I don't seem to have that variable defined.  Not surprising since
there's no include or lib directories like that on MVS.

> It is important to get this cross-compiler working correctly, i.e.
> refering to the proper headers and libraries, because in the next
> step, when you configure and build the native compiler, you'll be
> using the cross-compiler, and what headers it uses will determine
> which host features are detected by configure ...

I see.  Anyway, I'll start with raw 3.4.6 and move forward from
there.  The good thing about doing it that way is that I know the end
result is actually achievable.

Gone are the dark days of the 3.2 port where I was doing a lot of
work, and had no idea whether at the end of all that work it would
all be wasted, because the compiler wouldn't run natively due to
some ASCII-specific bug beyond my ability to fix or work around.  :-)

BFN.  Paul.