On Tue, Sep 03, 2019 at 11:04:08PM +0200, Sid wrote:
> In /etc/make.conf, I have
> LD= /usr/local/bin/ld.lld80
>
> This is not used for ports. It may be used for building the kernel and world.
>
> clang-8: error: unable to execute command: Executable "ld" doesn't exist!
> clang-8: error: linke
On Wed, Aug 07, 2019 at 01:42:26PM -0700, Mark Millard wrote:
>
>
> On 2019-Aug-7, at 12:56, Brooks Davis wrote:
>
> > On Wed, Aug 07, 2019 at 11:55:04AM -0700, Mark Millard wrote:
> >>
> >>
> >> On 2019-Aug-7, at 11:02, Brooks Davis wrote:
&
On Wed, Aug 07, 2019 at 11:55:04AM -0700, Mark Millard wrote:
>
>
> On 2019-Aug-7, at 11:02, Brooks Davis wrote:
>
> > On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote:
> >> On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
> >>>
On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote:
> On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote:
> > [I found something known to be missing in the
> > in at least some versions of
> > llvm/cmake/modules/CrossCompile.cmake that messes
> >
ark Millard wrote:
>
>
>
> > On 2019-Aug-6, at 19:08, Brooks Davis wrote:
> >
> >> On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
> >>>
> >>>
> >>> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
> >>&
On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote:
>
>
> On 2019-Aug-6, at 09:55, Brooks Davis wrote:
>
> > I'd prefer to disable this dependency. There's a knob that worked in
> > the 8.0 timeframe, but the lit build now autodetects z3 when it
I'd prefer to disable this dependency. There's a knob that worked in
the 8.0 timeframe, but the lit build now autodetects z3 when it is
present and I've failed to find a knob to disable it. For now, the easy
workaround is probably to disable options LIT. We could make that the
default on non-LLV
On Fri, May 03, 2019 at 09:33:42AM -0400, Ed Maste wrote:
> On Thu, 2 May 2019 at 14:03, Alfredo Dal Ava Junior
> wrote:
> >
> > Hi all,
> >
> > I'm working on having PowerPC64 using LLVM by default, but LLD support for
> > 32 bit seems to be incomplete. As workaround I'm using ld.bfd (2.17) for
On Mon, Feb 25, 2019 at 10:50:40AM -0800, John Baldwin wrote:
> On 2/22/19 6:03 PM, Brandon Bergren wrote:
> >
> >
> > On Fri, Feb 22, 2019, at 1:01 PM, John Baldwin wrote:
> >> 3) I add support for an /etc/src.conf.d dir that can hold files that get
> >>treated as if they are part of /etc/sr
Fixed in r340371.
Thanks,
Brooks
On Fri, Nov 09, 2018 at 08:27:44PM -0800, Mark Millard via freebsd-toolchain
wrote:
> (Leading whitespace might not be preserved.)
>
> # svnlite diff /usr/src/Makefile.libcompat
> Index: /usr/src/Makefile.libcompat
> =
On Thu, Nov 01, 2018 at 08:57:24AM -0400, Charlie Li wrote:
> On 29/10/2018 20:11, Konstantin Belousov wrote:
> > Author: kib
> > Date: Tue Oct 30 00:11:30 2018
> > New Revision: 339898
> > URL: https://svnweb.freebsd.org/changeset/base/339898
> >
> > Log:
> > Convert amd64_get/set_fs/gsbase to
On Wed, Jun 20, 2018 at 10:46:46AM -0400, Ed Maste wrote:
> Work is in progress to migrate fully to modern and permissively
> licensed components for the tool chain. This includes moving away from
> the three obsolete binutils components that are still in the base
> system (as, ld, objdump). objdum
On Tue, Apr 03, 2018 at 04:44:10PM -0400, Shawn Webb wrote:
> On Tue, Apr 03, 2018 at 08:32:10PM +0000, Brooks Davis wrote:
> > We (mostly Ali) are working on a patch to to split the actual syscalls
> > (__sys_) out of libc and into a libsys. For dynamic linking,
>
We (mostly Ali) are working on a patch to to split the actual syscalls
(__sys_) out of libc and into a libsys. For dynamic linking,
this is fairly straightforward (link libc against libsys, maybe as a
filter). For static linking, I'm looking for feedback on the right
approach. Do we link libsys.
I'll work on this.
-- Brooks
On Thu, Nov 09, 2017 at 07:09:00PM -0800, Mark Millard wrote:
> [ devel/llvm* also have the issue in their
> lld 's.]
>
> On 2017-Nov-7, at 4:43 PM, bugzilla-noreply at freebsd.org wrote:
>
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223383
> >
> > --- Co
there's a bootstrapping bug of some sort of LLD so -DWITHOUT_LLD
is required.
I suspect mips64 is close to working, but haven't tested it yet.
-- Brooks
On Sat, Apr 08, 2017 at 12:13:58AM +, Brooks Davis wrote:
> Author: brooks
> Date: Sat Apr 8 00:13:58 2017
> New R
On Thu, Mar 30, 2017 at 07:26:19PM +0200, Dimitry Andric wrote:
> On 30 Mar 2017, at 19:06, Alexey Dokuchaev wrote:
> >
> > On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote:
> >> On 26 Mar 2017, at 23:36, Mark Millard wrote:
> >>> ...
> >>> Also interesting was:
> >>>
> >>> Instal
On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote:
> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote:
>
> > On 26 Mar 2017, at 23:36, Mark Millard wrote:
> >>
> >> I upgraded from llvm40 r4 to final. An interesting result was
> >> its creation of a backup package for llvm40-4.0.0.r4
brooks accepted this revision.
brooks added a comment.
This revision has a positive review.
Looks good to me
REVISION DETAIL
https://reviews.freebsd.org/D3190
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: emaste, bapt, brooks
Cc: freebsd-toolchain-list
brooks accepted this revision.
brooks added a comment.
Looks good to me
REVISION DETAIL
https://reviews.freebsd.org/D3175
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: emaste, bapt, imp, brooks
Cc: freebsd-toolchain-list
brooks accepted this revision.
brooks added a comment.
This revision has a positive review.
Looks good to me.
REVISION DETAIL
https://reviews.freebsd.org/D2338
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: emaste, brooks
Cc: brooks, freebsd-toolchain-li
brooks added a comment.
Is this still live?
REVISION DETAIL
https://reviews.freebsd.org/D2338
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: emaste, brooks
Cc: brooks, freebsd-toolchain-list
___
freebsd-toolcha
brooks accepted this revision.
brooks added a comment.
This revision has a positive review.
Looks good to me.
REVISION DETAIL
https://reviews.freebsd.org/D2408
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: emaste, brooks
Cc: freebsd-toolchain
__
brooks added a comment.
s/MK_ELFTOOLCHAIN_TOLOLS/MK_ELFTOOLCHAIN_TOOLS/ required :)
REVISION DETAIL
https://reviews.freebsd.org/D2408
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: emaste, brooks
Cc: freebsd-toolchain
brooks added a subscriber: brooks.
brooks accepted this revision.
brooks added a reviewer: brooks.
brooks added a comment.
This revision is now accepted and ready to land.
Looks good to me.
REVISION DETAIL
https://reviews.freebsd.org/D2338
To: emaste, brooks
Cc: brooks, freebsd-toolchain
_
It appears that I added powerpc64 (and several others) to the
devel/llvm* ports version of this patch, but didn't do it for
lang/clang*. I'll sync them up.
-- Brooks
On Tue, Mar 17, 2015 at 08:02:47PM -0700, Mark Millard wrote:
> patch-utils_llvm-build_llvmbuild_main.py is missing a powerpc64 en
On Mon, Feb 16, 2015 at 01:21:34PM -0800, Craig Rodrigues wrote:
> On Wed, Feb 11, 2015 at 1:43 PM, Dimitry Andric wrote:
>
> >
> > Yes, choose either lang/clang-devel, or lang/clangXY, where XY is the
> > version you are interested in.
> >
> >
> > > (2) is there enough llvm source in FreeBSD
On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote:
> Hi,
> A common pattern that I've seen at Isilon and something else that I've
> wanted to have for a while is the ability to designate where the top of a
> source tree was. This is important and helpful when dealing with source
>
On Wed, May 01, 2013 at 02:35:17PM -0700, Garrett Cooper wrote:
> Hi Brooks and Joel,
> I'd really appreciate if you guys could help out with this. I'm
> having to fix the Isilon build system due to severe lack of
> documentation in build(7). So many mistakes have been made because
> people do
On Wed, Apr 24, 2013 at 09:15:30AM -0700, Garrett Cooper wrote:
>
> On Apr 23, 2013, at 10:28 AM, Garrett Cooper wrote:
>
> > On Apr 23, 2013, at 9:59 AM, Brooks Davis wrote:
> >
> >> On Fri, Apr 19, 2013 at 11:17:50PM -0700, Garrett Cooper wrote:
> >>&g
On Fri, Apr 19, 2013 at 11:17:50PM -0700, Garrett Cooper wrote:
> Hi arch@ and toolchain@,
> One of the items that I'm proposing be added to Makefile.inc1 in
> order to make building and installing tests on CURRENT (ATF and
> otherwise) is a build knob called TESTS_WITH_WORLD (the name can be
>
On Sun, Jan 13, 2013 at 12:24:35PM -0800, John-Mark Gurney wrote:
> Nathan Whitehorn wrote this message on Sun, Jan 13, 2013 at 10:14 -0800:
> > On 01/13/13 09:13, Konstantin Belousov wrote:
> > > On Sun, Jan 13, 2013 at 08:21:37AM -0800, Nathan Whitehorn wrote:
> > >> On 01/13/13 05:20, Konstantin
On Fri, Oct 12, 2012 at 03:42:20PM +0300, Andriy Gapon wrote:
>
> Gerald,
>
> $ gcc46 --version
> gcc46 (FreeBSD Ports Collection) 4.6.3
>
> I think that the above should have just "gcc" instead of "gcc46". The
> version is
> reported separately from the compiler name.
> The above output confu
On Mon, Sep 17, 2012 at 10:06:42PM +0200, Dimitry Andric wrote:
> On 2012-09-17 21:10, Brooks Davis wrote:
> > Now that we have the COMPILER_TYPE variable I'm following up on an idea
> > by theraven@ that we should enable libc++ by default when we are
> > building
On Mon, Sep 17, 2012 at 01:36:53PM -0600, Warner Losh wrote:
>
> On Sep 17, 2012, at 1:10 PM, Brooks Davis wrote:
> > Now that we have the COMPILER_TYPE variable I'm following up on an idea
> > by theraven@ that we should enable libc++ by default when we are
> > b
Now that we have the COMPILER_TYPE variable I'm following up on an idea
by theraven@ that we should enable libc++ by default when we are
building world with a compiler that supports it. The following patch
implements this:
http://people.freebsd.org/~brooks/patches/libc%2b%2b-default.diff
One key
On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote:
> On Thu, Sep 13, 2012 at 09:32:12AM -0600, Ian Lepore wrote:
> > On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote:
> > > In regards to my initial post in this thread, I was just trying
> > > to assess whether any benchmarks have been
On Wed, Sep 12, 2012 at 09:49:51PM +0900, Yamaya Takashi wrote:
> In Makefile.inc1,
> both WMAKECOMPILER_TYPE and WMAKE_COMPILER_TYPE exist.
> It's maybe bug.
It is. I'm not actually sure why it didn't result in more invocations
of gcc in my test. I'm testing a fix now.
-- Brooks
pgpKVIZxGLt7
On Wed, Sep 12, 2012 at 03:43:39AM -0500, Warner Losh wrote:
>
> On Sep 10, 2012, at 4:56 PM, Brooks Davis wrote:
> > .if ${COMPILER_TYPE} != "clang"
> >
> > I'd like to commit this in the next few days unless there are objections
> > requiring a majo
On Tue, Sep 11, 2012 at 06:29:00PM -0700, Darren Pilgrim wrote:
> On 2012-09-10 14:12, Brooks Davis wrote:
> > [Please confine your replies to toolch...@freebsd.org to keep the thread
> > on the most relevant list.]
> >
> > For the past several years we've bee
On Tue, Sep 11, 2012 at 01:45:18PM +0300, Konstantin Belousov wrote:
> On Mon, Sep 10, 2012 at 04:12:07PM -0500, Brooks Davis wrote:
> > For the past several years we've been working towards migrating from
> > GCC to Clang/LLVM as our default compiler. We intend to ship F
On Mon, Sep 10, 2012 at 05:22:37PM -0400, Daniel Eischen wrote:
> On Mon, 10 Sep 2012, Brooks Davis wrote:
>
> > [Please confine your replies to toolch...@freebsd.org to keep the thread
> > on the most relevant list.]
> >
> > For the past several years we've
Currently, when WITH_CLANG_IS_CC is set for the first time (/usr/bin/cc
is gcc) you must also set CC=clang, CXX=clang++, and CPP=clang-cpp.
This is due to the fact that we currently hardcode knowledge of which
compiler cc is and key if off of WITH_CLANG_IS_CC. Thus while building
things required t
[Please confine your replies to toolch...@freebsd.org to keep the thread
on the most relevant list.]
For the past several years we've been working towards migrating from
GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD
10.0 with Clang as the default compiler on i386 and amd64
On Thu, May 12, 2011 at 12:02:08PM -0400, Eric Will wrote:
> The current Makefile for devel/llvm doesn't allow you to use
> REQUIRES_RTTI. It's a pretty common option, and is even enabled by
> default in devel/llvm-devel. I emailed the maintainer months ago and
> haven't had a response or seen any
45 matches
Mail list logo
