From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 9D0EF3945C16 for ; Mon, 14 Mar 2022 13:12:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9D0EF3945C16 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-492-kGAuF8znOkG2ZXJsihx9pA-1; Mon, 14 Mar 2022 09:12:18 -0400 X-MC-Unique: kGAuF8znOkG2ZXJsihx9pA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8577A106655C; Mon, 14 Mar 2022 13:12:17 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.88]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0B35A202A423; Mon, 14 Mar 2022 13:12:14 +0000 (UTC) From: Florian Weimer To: Cc: , , "'Shiva Subramanian'" , "'Bill Honaker'" , Subject: Re: Re-port Intent for HPE NonStop (a.k.a. Tandem) References: <01ec01d836d7$f59d39a0$e0d7ace0$@nexbridge.com> <87k0cxynn8.fsf@oldenburg.str.redhat.com> <025601d837a1$ce111d00$6a335700$@nexbridge.com> Date: Mon, 14 Mar 2022 14:12:12 +0100 In-Reply-To: <025601d837a1$ce111d00$6a335700$@nexbridge.com> (rsbecker@nexbridge.com's message of "Mon, 14 Mar 2022 08:48:22 -0400") Message-ID: <877d8wy8yb.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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 13:12:24 -0000 >>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