From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id 10A8A3858C52 for ; Thu, 21 Dec 2023 12:03:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 10A8A3858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cebitec.uni-bielefeld.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 10A8A3858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.70.160.84 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703160213; cv=none; b=UvSn+/hosvcI6PHYuJ8JFZ7yfe61JkHMJcbA6XQmOOJnCwnwDO+TEfBDsQwS0rMLuSfXK6afxytJ4aZ94pgFH7ZAXtarWHwOyWrVK8MxbtdqOGTXEdj8+vPWo9cPTwqNTFUvf1Ju+d08Jp2x2Sx7EJgqcj3aumlRfoGqhgLpCkU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703160213; c=relaxed/simple; bh=2Z63qrJzwOsVzaSmV8Iypkrzzz5wPPeaP8Oc+NJBQV8=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=ryaADyYe30bDLkHr6gdocU7WeCeMR6s2MmHZmDQ2t3mZdX/MAvTSxsr+hhvBeQ0mIgVoMFnM3l9cNhnkBVhhDgL8ExHmapVHinSTako6gWjc1DwIzTKvtDGs8UxWu4E22D3XJqpdBfsdV6sZBPqOb45ITUTqWMMy52BW8bJf8J4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id DCEFBBBFC9; Thu, 21 Dec 2023 13:03:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= cebitec.uni-bielefeld.de; h=content-type:content-type :mime-version:user-agent:message-id:in-reply-to:date:date :references:subject:subject:from:from:received:received; s= 20200306; t=1703160209; bh=2Z63qrJzwOsVzaSmV8Iypkrzzz5wPPeaP8Oc+ NJBQV8=; b=VOcTe70cayjD4U1PyyA/PLPdpY6HhI1w/FsCKRWS8qxzjnq42C5Rn aH8JmK6nkjLIxD8kmiwuczyL1MKsatD5bN2uYwYdc5UHMGHrRRZjtcUShuOIFmjc 1j21zn5lfDFcIq5XJWW0Acim1ZE43QRQ5Ai/SrkoIx8ebVR6RA+Jx0FwUQxobc+F j1PRYPnr4u2MCfdH0DW3FFf6Cym+0G2m4B37vkP2qX8w2WycX4b6fkds/Xr3fhqX RWw27/lCgAi9uMtJ8kH4C154dfEKbve7mbFyWtkgbxwDpcGhLesWO+3U3965Xl5J dKBx3ZbsE8oWMBcqeCR1aYYjtuuewMr6A== X-Virus-Scanned: amavisd-new at cebitec.uni-bielefeld.de Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5yoqfumLiXDy; Thu, 21 Dec 2023 13:03:29 +0100 (CET) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p4fddb508.dip0.t-ipconnect.de [79.221.181.8]) (Authenticated sender: ro) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id 58F43BC2E3; Thu, 21 Dec 2023 13:03:29 +0100 (CET) From: Rainer Orth To: John Baldwin Cc: Jan Beulich , binutils@sourceware.org Subject: Re: [PATCH] ld: Add lib32 directories for 32-bit emulation on FreeBSD/amd64 References: <6499aee9-3935-41c1-8897-a177f6173e8a@FreeBSD.org> Date: Thu, 21 Dec 2023 13:03:29 +0100 In-Reply-To: <6499aee9-3935-41c1-8897-a177f6173e8a@FreeBSD.org> (John Baldwin's message of "Wed, 20 Dec 2023 09:47:22 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3785.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KAM_NUMSUBJECT,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi John, >>> ... it doesn't look implausible that things may have worked on earlier >>> versions (or else perhaps someone would have noticed long ago), and that >>> hence your change might break things there. >> I'm certain they didn't: I originally developed this patch 4 years ago, >> but either forgot to submit it back then or hoped an active member of >> the FreeBSD community would. This must have been in the FreeBSD 11 or >> 12 timeframe, and obviously nothing has happened/been improved since. > > FreeBSD has always used /usr/lib and for the "native" ABI and /usr/lib32 for > 32-bit ABIs on 64-bit platforms. This includes both i386 on x86-64 as well > as 32-bit powerpc on powerpc64 and more recently 32-bit arm (armv7) on > aarch64. Given that, I believe the patch to be correct (and it likely applies > for powerpc64* using "powerpc" emulation and aarch64* using "armv7" emulation). good to see one platform that is consitent across architectures here ;-) Given that I don't have access to any of the other FreeBSD platforms, I'll leave such a patch to those that do. >> My recent forays into FreeBSD have been less than pleasant, >> unfortunately: see GCC PR target/112959 (install.tex needs updates on >> FreeBSD) for an overview of the issues on the GCC side. It seems the >> FreeBSD community either cares little about GCC and binutils these days >> (having moved to lld as /usr/bin/ld and clang/clang++), or doesn't >> believe in upstream bug reports, let alone submitting patches ;-( This >> is not just about GCC/binutils; the same seems to happen on the LLVM >> side where they completely ripped out the cmake-based build system and >> replaced it with one of their own (based on BSD make). Trying to build >> upstream LLVM on FreeBSD is just as unpleasant as GCC. E.g. GCC won't >> work with lld (cf. GCC PR target/112745), so you need GNU ld here... > > While LLVM is the primary toolchain for FreeBSD, GCC is not completely > ignored. I maintain a set of ports for GCC packages customized to build > FreeBSD's base system. I recently added a new port for GCC 13 for this > purpose and can currently build FreeBSD's development trunk (userland + > kernel) on x86-64 with both GCC 12 and GCC 13. (Right now GCC 12 is > used in a CI job in FreeBSD's CI infrastructure, and the GCC 13 job is > being added this week or next.) There are regular posts of FreeBSD testresults to the gcc-testresults list, so you are not alone here. This matches what the Oracle Solaris guys do for both their solaris-userland repo and use of GCC as a shadow compiler building OS/Net (the core OS including kernel and Solaris userland). > I do have a couple of patches to GCC I should post upstream (switching > i386 to default to -march=i686 in newer versions, and adding a > __freebsd_kprintf__ format for the in-kernel printf() function), just > haven't done paperwork yet on the GCC side. Good: maybe the other issues I've found building GCC trunk on FreeBSD can also be resolved and the experience for non-FreeBSD developers become a bit smoother in the future. I believe both those GCC developers (testing their patches on more platforms) and FreeBSD (having less patches that break their builds) would benefit from that. > In regards to the build system, FreeBSD's entire base system builds with > a single build infrastructure using make (and always has). For any > external tool used in the base, build glue written in make is used. This > was true of GCC and binutils when they were part of base as well. I won't argue with that. What becomes problematic IMO is when you cannot build upstream GCC or LLVM without additional patches: having to investigate build problems before you even get to testing your own patches takes a patience that few developers will have. Thanks for your explanations. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University