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

[<rsbecker@nexbridge.com>]

On March 14, 2022 3:55 AM, Florian Weimer wrote:
>> I have been asked by members of the HPE NonStop (formerly Tandem)
>> community to consider re-porting Glibc to the platform. There was a
>> port back around
>> 2.12 but that never made it to x86.
>
>It must have been a private port, not released to the general public.

The port was released to the public, but not through standard glibc
mechanisms. Both binaries and sources were available to the NonStop
community.

>Does HPE NonStop provide a stable kernel interface?  Linux is somewhat
unique in
>that.  Other systems require some level of synchronization between libc and
>kernel updates.

Yes. The kernel is highly stable, with HPE providing long-term compatibility
statements. The POSIX components date back to 1995 and continuously
upgraded. To date, source compatibility has been maintained even across
chipset changes.

>> The current situation is that the platform is not on the list of known
>> ports. Glibc is a dependency of many projects that we want to bring to
>> the platform. How can this be pursued? My team is willing to
>> officially support the port once done. Although POSIX compliant, we
>> are limited to using a c99 compiler. gcc does not port, making this
>> interesting.
>
>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.

>We need a publicly available, free (libre) toolchain for any port.  This is
both a
>matter of policy, and also to prevent the port from bit-rotting.

I have successfully done ports of other products with the same constraint
(git, openssh, openssl). Usually ports are possible with minimal changes. I
would like to do a bit of an impact analysis to see how difficult this one
would be. Glibc is an ongoing concern because it is a dependency for many
Open-Source projects.

>> Note: The link http://www.gnu.org/software/libc/development.html on
>> your wiki page https://sourceware.org/glibc/wiki/#Development gets a 404.
>
>I've removed this section because it is outdated.  I'm not sure if we would
accept
>ports to new kernels at this point.  (New targets is a different matter.)

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

Thanks,
Randall