This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: i370 port - constructing compile script


"Paul Edwards" <mutazilah@gmail.com> writes:

>>>> * 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.  fputs_unlocked is called by gcc itself, not by target
code; 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.

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.


>> 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.

> 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.


> 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.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]