From owner-freebsd-arch@freebsd.org Mon Oct 9 05:26:55 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6AFBE25984 for ; Mon, 9 Oct 2017 05:26:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4894E7616E for ; Mon, 9 Oct 2017 05:26:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id i38so7837730iod.2 for ; Sun, 08 Oct 2017 22:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yzTwLyGNDftZLEP3nQrns89bw7Sej8S7ql1QYA/0JHI=; b=IO0UTOHED2xYYujgeUeU3emJZpzA/No7vzKY/2oZjfZUHJneqE8+kqMvNGyEskv5Ta Uk8zNxzY3kOFWBM0JBpdeUGKFEUeZiq5u0Y4KwRm00lTo35L58Ui/rmEvZz5acUTlvTN R/imu0T3E9Qe1OPZb9tVkHLzAGgeaV18wKyBfo+3myr7wavek8d9q8JhsVO7DJ4LG2RR ujNdWZQuEsExKYmhWsWASPCNzSq0X4VL0YQd0ixlB3U3IK4JYoOFYjYks+jb3ThgrARn FQWpqSLVEG2WnaGsgcz4Mqz0Fe05sg3NHj6uK8LydsgW7hkeNamLj9ovt+9e31a8op90 BL2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yzTwLyGNDftZLEP3nQrns89bw7Sej8S7ql1QYA/0JHI=; b=fvvp8zZCZQ/Id6V/IWS97cWOHSIbHdyULlS38mtmKjsiniJzP8hRXNvFB96RDVJk0U 0lWQrsEmYY39OuIzuyBJeNs9rTg+T3/L7+p+vEvLj2UrBQmDRVzxDhCsyp6m8wC1BON7 3Q1lDEr3UD36XbzDkFl39+rCsNel4trUO2mOwECrkXV857UbFGBS5J7RCkS0/IqfMhN9 o9cErnzzuKRTCv/XNR1jWlCleWj2MtUHSSUKv4Ho+tnq2VVL5CruwWtI5I0Jas2OKdYC TkdGi8CHCpoa+sz7FAStV0FxNVte/8EhGlFxesaGYJsZqJq2tQLy2LdxLeiQL32bagQA cZOQ== X-Gm-Message-State: AMCzsaXZHmkNo3SyW8ryxSrVE+SUb2DBRgoNw/QyGsylFOWMXDzDbdZf UDlmLsz7RLfXWLG7H2fHEO/n9oBj92rNF+useiMyZA== X-Google-Smtp-Source: AOwi7QAlKAFNKzJag/FgLEm2Pn2AlV9Lo+C0yRVpEvRR3sjPSv8jiFTTHUskc24uh6FI6aGzAgpLAcR1zJ5FvK7gFcQ= X-Received: by 10.107.135.202 with SMTP id r71mr3862665ioi.26.1507526814427; Sun, 08 Oct 2017 22:26:54 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.94.130 with HTTP; Sun, 8 Oct 2017 22:26:53 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:8936:338a:89de:d5ea] In-Reply-To: References: <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> From: Warner Losh Date: Sun, 8 Oct 2017 23:26:53 -0600 X-Google-Sender-Auth: nHonnO7aCyfewxA8jvmPhRQ9Z2E Message-ID: Subject: Re: Making C++11 a hard requirement for FreeBSD To: Nathan Whitehorn Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 05:26:55 -0000 On Sun, Oct 8, 2017 at 11:01 PM, Nathan Whitehorn wrote: > > > On 10/06/17 00:20, Baptiste Daroussin wrote: > >> On Thu, Oct 05, 2017 at 11:47:57PM +0000, John Baldwin wrote: >> >>> On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: >>> >>>> I'd like to start a conversation about the viability of making C++11 a >>>> hard >>>> requirement for bootstrapping FreeBSD and setting a specific deadline >>>> for >>>> doing so. >>>> >>>> This discussion is motivated by an ask from the jemalloc folks to use a >>>> limited subset of C++11 inside of malloc in such a way that is C safe >>>> (so >>>> the C programs wouldn't bloat with a C++ runtime). That's an ongoing >>>> discussion in another forum, and isn't appropriate for this thread >>>> because >>>> this has become a frequent request (but if you have opinions, please >>>> find >>>> the thread in current@ about it). I don't know the timeline of their >>>> plans >>>> to do this. >>>> >>>> I'd like to take the rather vague plans we've had "before 12" and >>>> create a >>>> timeline for removal of gcc 4.2 coupled with a requirement for support >>>> in >>>> clang or a working external toolchain. This requirement would be coupled >>>> with the requirement that the external toolchain support C++11 >>>> constructs. >>>> >>>> I'd like to propose we do this 12/31/17. Any architectures that can't >>>> meet >>>> this timeline will be disconnected from universe at that time and >>>> deleted >>>> 3/31/18. >>>> >>>> It's my belief that i386, amd64, arm, aarch64, powerpc and powerpc64 are >>>> ready for this change and mips* would be ready for this change with an >>>> external clang toolchain. I'm unsure of riscv and sparc64, but suspect >>>> that >>>> a newer version of gcc as an external toolchain could work. >>>> >>> In-tree clang 5.0 for MIPS mostly works (modulo some small patches). >>> However, >>> it requires external ld.bfd. I know that there ld.lld can link a working >>> mips64 world with some patches (notably the multigot patch). mips works >>> fine >>> with external GCC. riscv is already using external GCC that is >>> C++11-capable. >>> >>> The problem with external GCC is that you can cross-build a world + >>> kernel >>> just fine and get a working system via CROSS_TOOLCHAIN=foo-gcc. However, >>> that system has no viable '/usr/bin/cc' once GCC 4.2 is removed. bapt@ >>> started on ports to cross-build binutils and gcc packages via the base/* >>> ports, but those are not yet finished / fully tested. I don't think >>> anyone >>> has thought about how release builds will work either with only an >>> external >>> toolchain available. (I'm pretty sure sparc64 has booted fine with >>> external GCC, it's just in the same boat as mips with regard to >>> /usr/bin/cc.) >>> >> Actually I did test those and they were working (tested in qemu) they were >> working fine. I have given up working on them due to the lack of >> interested by >> the community (by interest I mean people really testing, working on it, >> not just >> saying "hey nice sounds cool"). >> >> As for the boot when I initially worked on external toolchain sparc64 was >> my >> guinea pig and so yes it worked an booted just fine. >> > > So far as I know, we never solved any of the infrastructural problems > associated with this concept: > 1. Providing built releases with a /usr/bin/cc > 2. Coversioning base and in-ports toolchain, including ensuring commit > atomicity between toolchains and libc > 3. Adding a dependency on ports for src, including out-of-tree code that > has to be fetched from external servers > 4. Getting make universe to do the right thing > > We really need to solve those. If we go the external toolchain route, > which it is not clear to me is the best option, #2 and #1 are quite complex > problems. I think that, frankly, a deadline in two months to solve this set > of political problems we have had for two years is probably crazy, but > maybe making the status quo unsustainable will finally force progress. > External toolchains have been in flight for 5 or more years now. It's time they land. Though the requirements for them have never included cross-threading between /usr/src and /usr/ports like you suggest above, and those sorts of things won't be sorted by my deadlines (which are closer to 3 months). Nor, imho, should they. > Also, are there any directions for how to build a toolchain from the base > ports? I haven't been able to figure it out -- the README starts with "pkg > install", but that doesn't get me very far on platforms without binary > packages, which are the ones this is meant to target. External toolchains are by definition external. Not part of the tree nor integrated into the tree. How you get them depends on the external toolchain and is unspecified. You get a lower level of integration than you do with in-tree toolchains, not the same level with reach-overs into some external repo. Warner