From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elephants.elehost.com (elephants.elehost.com [216.66.27.132]) by sourceware.org (Postfix) with ESMTPS id AA7B13858D37 for ; Mon, 14 Mar 2022 12:48:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AA7B13858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nexbridge.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=nexbridge.com Received: from Mazikeen (cpe00fc8d49d843-cm00fc8d49d840.cpe.net.cable.rogers.com [99.229.22.139] (may be forged)) (authenticated bits=0) by elephants.elehost.com (8.16.1/8.16.1) with ESMTPSA id 22ECmRFY085387 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Mar 2022 08:48:28 -0400 (EDT) (envelope-from rsbecker@nexbridge.com) Reply-To: From: To: "'Florian Weimer'" Cc: , , "'Shiva Subramanian'" , "'Bill Honaker'" , References: <01ec01d836d7$f59d39a0$e0d7ace0$@nexbridge.com> <87k0cxynn8.fsf@oldenburg.str.redhat.com> In-Reply-To: <87k0cxynn8.fsf@oldenburg.str.redhat.com> Subject: RE: Re-port Intent for HPE NonStop (a.k.a. Tandem) Date: Mon, 14 Mar 2022 08:48:22 -0400 Organization: Nexbridge Inc. Message-ID: <025601d837a1$ce111d00$6a335700$@nexbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEXxrPuRx/llDaEPPRRpRc4hfKaWwFqVUXNrjRgXoA= Content-Language: en-ca X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_SHORT, MAY_BE_FORGED, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2022 12:48:36 -0000 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