Re: Re-port Intent for HPE NonStop (a.k.a. Tandem)

[Florian Weimer <fweimer@redhat.com>]

>>Can you use a GCC cross-compiler?
>
> No. GCC does not generate code that will run on the platform. While it is
> x86-based, there are complex endian concerns in the code generator,
> significant ELF header differences, and major ELF debug section differences
> that cannot be emitted by GCC. There have been at least 3 unsuccessful
> attempts I know of to port gcc to the platform and/or to generate cross
> compile code for it.

In this case, we would really need an open toolchain, otherwise we can't
maintain the ELF parts.

Keep in mind that glibc contains the dynamic linker, so it really has to
know about the details of your architecture.

> I have successfully done ports of other products with the same constraint
> (git, openssh, openssl). Usually ports are possible with minimal
> changes.

That's because you rely on the C run-time library to paper over the
differences in kernel interfaces.  With glibc itself, that's different.

> I would like to do a bit of an impact analysis to see how difficult
> this one would be.

You need to provide the rest of the toolchain first, and that seems to
require a major effort (and it's not just about writing code).

I also doubt that we would accept patches which retarget to a
proprietary kernel, but that depends on how invasive those patches are.

> How should I proceed, if I need glibc as a dependency?

You need to port GCC and binutils first, and then you can proceed with
glibc.  It's how new ports are brought up.  I'm not aware of any other
port in recent times that has been done in a different way (not using
GCC).  This is not me being snarky, it's just that the GNU toolchain
(binutils/GCC/GDB/glibc) is an integrated whole and works best in
conjunction.

It might be possible to get away with an LLVM-based toolchain, but the
porting of glibc istelf to LLVM is not yet complete, so you would
struggle on this front as well.

Thanks,
Florian