This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: i370 port - constructing compile script
* Copy header files and libraries from the host (MVS).
That's fine. And use the --with-root option of configure to get
them used?
--with-sysroot, yes.
I have been trying combinations of --prefix and --with-sysroot, and
--with-build-sysroot, but it is still insisting that I have an
fputs_unlocked etc, despite pointing all those things to a
directory that has no such thing in it, and just has my C90
headers.
The --with-sysroot option tells gcc where to find header files and
libraries for the target. The --with-build-sysroot option tells gcc
where to find header files and libraries for the target while building
gcc itself.
But that's the first step in what I'm doing, isn't it?
fputs_unlocked is called by gcc itself, not by target code;
As such, I am in a position where I can point it to my C90 libraries.
I have everything I need to create the xgcc as a single executable
on Linux that produces i370 assembler. That's what I already have
with gcc 3.4.6.
With 3.4.6, I have a script called "compile", which looks like this:
call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bb-reorder.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bitmap.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bt-load.c %1 %2 %3 %4 %5 %6 %7 %8 %9
...
gcc -s -nostdlib -o gccmvs.exe *.o ../../pdos/pdpclib/pdpwin32.a -lkernel32
The Windows version is simpler, but I have the equivalent for Linux.
I call it gccmvs instead of xgcc.
That's my cross-compiler.
That was sort of hand-constructed (I actually selected stuff from
the output of a normal make on Linux, skipping stuff that was
used to produce the generator files (genrecog etc).
I believe that a simple script like above can be *generated* with a
few lines of changes to an appropriate makefile. That's why I
mentioned before that I'm after a makefile target that only lists
the object code that would go into a stage 1 executable.
therefore, what matters for whether fputs_unlocked is supported
is the host header files and libraries, not the target header files
and libraries. So using --with-sysroot is never going to affect
whether gcc itself uses fputs_unlocked.
Well even with --with-build-sysroot I don't seem to be able to
steer it away from my system's header files. But this is a
more minor aspect to what I'm interested in. I think I'll just
rename my system header files and copy in the C90
headers.
The case where that should work if you configure gcc using
--with-sysroot to point to C90 headers and libraries, and you use that
gcc to build another gcc. That is, configure gcc as a cross-compiler
to a system which happens to be very similar to the host system, and
then use that cross-compiler to build a new compiler, in what is
effectively a same-system Canadian Cross. The second gcc should not
use fputs_unlocked in that case.
This comment has me confused.
I already have gcc 4.4 installed as a native compiler. I am now
trying to build on Linux, to produce a Linux-to-i370 cross-compiler.
Therefore the first thing I want to do is build a cross-compiler,
right? Or does the build process want to force me to compile
gcc 4.4 as a native compiler *again*? I was expecting it to just
use what I already have, which coincidentally happens to be
gcc 4.4. Can I skip that step then? I (used to) sometimes use
a different compiler, such as Watcom or Borland, on Windows,
in order to build the windows-to-i370 cross.
Similarly, getrlimit and getrusage are entirely optional. They are
used if available, otherwise not.
Right. I'm having trouble getting it to ignore the ones that are
installed
on the build system, and to switch to the directory given with
--with-sysroot.
When talking about this kind of thing, you have to distinguish the
build system and the host system. The header files on the build
system are irrelevant. The header files on the host system are what
matter. Normally the build system and the host system are the same,
but this is not true when building with a cross-compiler.
In my case, I intend to run the cross-compiler on Linux to make sure
it works. On Linux I also want to generate the compile script, and
to generate the JCL.
Once I have all those things (on the best system for gcc tools), I
then want to package it all up and move to Windows.
There I will run the compile script (shown above), and make sure that
it also produces a single executable. I will use gcc 3.4.4 for that task,
because it comes by default with Cygwin. I may choose to use
Borland etc instead, but unlikely.
At this stage I will be confident that I have a single C90-compliant
executable, and the challenge becomes whether I can reproduce
that on MVS.
So I run a slightly different script, compmvs, which looks like this:
call stdcompm alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm bb-reorder.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm bitmap.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm bt-load.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm builtins.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm caller-save.c %1 %2 %3 %4 %5 %6 %7 %8 %9
stdcompm.bat:
gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CONFIG_H -DIN_GCC
...
Once I have the assembler code, I zip it up, then use my Linux-generated
JCL and pass it all over to MVS to see if it can assemble a stage 1
executable, which is how I have a 3.4.6 MVS executable.
Also, for the long term, it would be better to
distinguish the headers that I use on the build system, to the
headers used when cross-compiling. As I mentioned, I happen
to be in a position where I can use the same ones on MVS, on
Linux (and some other platforms too), so I can get away with
forcing it to the C90 headers immediately.
gcc has no confusion between the headers on the host system and the
headers on the target system. I don't know precisely how to map that
onto your comment about the build system and the headers used when
cross-compiling.
Ok, I'm lost even further up the process now.
I'm not sure whether to call MVS a target or host.
There's not much I can do about the non-acceptance of the mods,
but the one thing I can do is keep my modification footprint low.
That's why I believe that 20 lines somewhere in the configuration
scripts are probably enough to get what I want, without upsetting
the existing structure. Maybe eventually those 20 lines will be
accepted as a non-default option, but that is beyond my control.
If you can demonstrate that 20 line configure script change, then we
can certainly discuss it. I personally am rather skeptical that you
can rewire gcc's build process in 20 lines.
It's about 20 lines of intrusive code to combine GCC into a single
executable, bypassing the need for a system() or similar call.
Why would this be any different?
The gcc build process *already* compiles each module.
All I need to do is restrict the list of modules, and add the "-S"
option, and then tell it to not complain about the ".o" not being
generated, because I produced a ".s" instead.
Doesn't sound like a lot of work if I can figure out where to put
it, and the "-S" and a touch of ".o" can go into an external
script to even eliminate that intrusion! :-)
BFN. Paul.