Re: llvm port does not allow REQUIRES_RTTI
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 changes. I've never done anything
> with ports before, but my best stab at it is below.
Sorry for dropping the ball on this. I'll try to get it done soon. The
best way to submit this sort of change is via the PR system.
-- Brooks
>
> Thanks,
>
> -- Eric Will
>
> --- /usr/ports/devel/llvm/Makefile 2011-04-29 11:04:29.0 -0400
> +++ Makefile2011-05-12 11:52:59.0 -0400
> @@ -40,6 +40,7 @@
> CONFIGURE_ARGS+= --enable-bindings=none
>
> OPTIONS= ASSERTS "Enable assertions (thread unsafe)" off
> +OPTIONS+= REQUIRES_RTTI "Enable run-time type IDs (RTTI)" on
>
> .if defined(NOPORTDOCS)
> CONFIGURE_ARGS+= --disable-docs
> @@ -70,6 +71,10 @@
> .else
> CONFIGURE_ARGS+= --disable-assertions
> .endif
> +.ifdef(WITH_REQUIRES_RTTI)
> +CONFIGURE_ENV+=REQUIRES_RTTI=1
> +MAKE_ENV+=REQUIRES_RTTI=1
> +.endif
>
> post-patch:
> ${REINPLACE_CMD} -e 's|\(PROJ_docsdir.*:=\).*$$|\1${DOCSDIR}|g' \
> ___
> freebsd-toolchain@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
>
pgp1wafz5jhgs.pgp
Description: PGP signature
Clang as default compiler November 4th
[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 platforms. To this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 platforms on November 4th. What does the mean to you? * When you build world after the default is changed /usr/bin/cc, cpp, and c++ will be links to clang. * This means the initial phase of buildworld and "old style" kernel compilation will use clang instead of gcc. This is known to work. * It also means that ports will build with clang by default. A major of ports work, but a significant number are broken or blocked by broken ports. For more information see: http://wiki.freebsd.org/PortsAndClang What issues remain? * The gcc->clang transition currently requires setting CC, CXX, and CPP in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@ to address this shortly. * Ports compiler selection infrastructure is still under development. * Some ports could build with clang with appropriate tweaks. What can you do to help? * Switch (some of) your systems. Early adoption can help us find bugs. * Fix ports to build with clang. If you don't have a clang system, you can use the CLANG/amd64 or CLANG/i386 build environments on redports.org. tl;dr: Clang will become the default compiler for x86 architectures on 2012-11-04 -- Brooks pgp7CmiVQcCNl.pgp Description: PGP signature
improving bootstrapping of WITH_CLANG_IS_CC
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 to build clang as a cross compiler we end up passing
clang CFLAGS to gcc.
I propose that we correct this by adding a new internal variable
COMPILER_TYPE which indicates which compiler we are using. For now it
just supports two values gcc and clang. Further refinement will be
required as we add support for external toolchains.
The following patch implements this feature. It allows me to complete
"make -DWITH_CLANG_IS_CC buildworld" and "make -DWITH_CLANG_IS_CC
installworld" on amd64 and survives a "make tinderbox".
The core logic lives in the new bsd.compiler.mk which determines which
type our compiler is from ${CC}. If ${CC} isn't a known compiler name
it is run with --version and we attempt to determine it from there. To
compensate for the fact that this is a) slow and b) the default case I
have patched Makefile.inc1 to set COMPILER_TYPE appropriately in the
environment of the submakes. In the stages leading up to cross build I
rely on bsd.compiler.mk. For the world stage I rely on knowing what
compiler will be built as a cross compiler. With these optimizations
we end up with four extra invocations of ${CC} which should not be
noticeable in practice.
The rest of the patch replaces things like:
.if ${MK_CLANG_IS_CC} == "no" && ${CC:T:Mclang} != "clang"
with things like:
.if ${COMPILER_TYPE} != "clang"
I'd like to commit this in the next few days unless there are objections
requiring a major redesign.
-- Brooks
Index: share/mk/Makefile
===
--- share/mk/Makefile (revision 240210)
+++ share/mk/Makefile (working copy)
@@ -3,7 +3,8 @@
FILES= bsd.README
FILES+=bsd.arch.inc.mk
-FILES+=bsd.compat.mk bsd.cpu.mk bsd.dep.mk bsd.doc.mk bsd.dtrace.mk
+FILES+=bsd.compat.mk bsd.compiler.mk bsd.cpu.mk
+FILES+=bsd.dep.mk bsd.doc.mk bsd.dtrace.mk
FILES+=bsd.endian.mk
FILES+=bsd.files.mk bsd.crunchgen.mk bsd.incs.mk bsd.info.mk
bsd.init.mk
FILES+=bsd.kmod.mk
Index: share/mk/bsd.compiler.mk
===
--- share/mk/bsd.compiler.mk(revision 0)
+++ share/mk/bsd.compiler.mk(working copy)
@@ -0,0 +1,20 @@
+# $FreeBSD$
+
+.if !defined(COMPILER_TYPE)
+. if ${CC:T:Mgcc} == "gcc"
+COMPILER_TYPE:=gcc
+. elif ${CC:T:Mclang} == "clang"
+COMPILER_TYPE:=clang
+. else
+_COMPILER_VERSION != ${CC} --version
+. if ${_COMPILER_VERSION:Mgcc} == "gcc"
+COMPILER_TYPE:=gcc
+. elif ${_COMPILER_VERSION:M\(GCC\)} == "(GCC)"
+COMPILER_TYPE:=gcc
+. elif ${_COMPILER_VERSION:Mclang} == "clang"
+COMPILER_TYPE:=clang
+. else
+.error Unable to determing compiler type for ${CC}
+. endif
+. endif
+.endif
Index: share/mk/bsd.sys.mk
===
--- share/mk/bsd.sys.mk (revision 240210)
+++ share/mk/bsd.sys.mk (working copy)
@@ -8,6 +8,8 @@
# for GCC: http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/Warning-Options.html
+.include
+
# the default is gnu99 for now
CSTD?= gnu99
@@ -28,8 +30,8 @@
.if defined(WARNS)
.if ${WARNS} >= 1
CWARNFLAGS+= -Wsystem-headers
-.if !defined(NO_WERROR) && ((${MK_CLANG_IS_CC} == "no" && \
-${CC:T:Mclang} != "clang") || !defined(NO_WERROR.clang))
+.if !defined(NO_WERROR) && (${COMPILER_TYPE} != "clang" \
+|| !defined(NO_WERROR.clang))
CWARNFLAGS+= -Werror
.endif # !NO_WERROR && (!CLANG || !NO_WERROR.clang)
.endif # WARNS >= 1
@@ -43,8 +45,8 @@
.if ${WARNS} >= 4
CWARNFLAGS+= -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow\
-Wunused-parameter
-.if !defined(NO_WCAST_ALIGN) && ((${MK_CLANG_IS_CC} == "no" && \
-${CC:T:Mclang} != "clang") || !defined(NO_WCAST_ALIGN.clang))
+.if !defined(NO_WCAST_ALIGN) && (${COMPILER_TYPE} != "clang" \
+|| !defined(NO_WCAST_ALIGN.clang))
CWARNFLAGS+= -Wcast-align
.endif # !NO_WCAST_ALIGN && (!CLANG || !NO_WCAST_ALIGN.clang)
.endif # WARNS >= 4
@@ -61,8 +63,7 @@
CWARNFLAGS+= -Wno-pointer-sign
# Clang has more warnings enabled by default, and when using -Wall, so if WARNS
# is set to low values, these have to be disabled explicitly.
-.if (${MK_CLANG_IS_CC} != "no" || ${CC:T:Mclang} == "clang") && \
-!defined(EARLY_BUILD)
+.if ${COMPILER_TYPE} == "clang" && !defined(EARLY_BUILD)
.if ${WARNS} <= 6
CWARNFLAGS+= -Wno-empty-body -Wno-string-plus-int
.endif # WARNS <= 6
@@ -89,20 +90,18 @@
.if ${WFORMAT} > 0
#CWARNFLAGS+= -Wformat-nonliteral -Wformat-security -Wno-format-extra-args
CWARNFLAGS+= -Wformat=2 -Wno-format-extra-args
-.if (${MK_CLANG_IS_CC} != "no" || ${CC:T:Mclang} == "clang") && \
-!defined(
Re: Clang as default compiler November 4th
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 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 platforms. To > > this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 > > platforms on November 4th. > > > > What does the mean to you? > > > > * When you build world after the default is changed /usr/bin/cc, cpp, and > > c++ will be links to clang. > > > > * This means the initial phase of buildworld and "old style" kernel > > compilation will use clang instead of gcc. This is known to work. > > > > * It also means that ports will build with clang by default. A major > > of ports work, but a significant number are broken or blocked by > > broken ports. For more information see: > > http://wiki.freebsd.org/PortsAndClang > > > > What issues remain? > > > > * The gcc->clang transition currently requires setting CC, CXX, and CPP > > in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@ > > to address this shortly. > > I assume this will be done, tested and committed before 2012-11-04 > (or whenever the switchover date is). Pending review it will be done this week. > > * Ports compiler selection infrastructure is still under development. > > This should be a prerequisite before making the switch, given > that ports will be broken without a work-around for building > them with gcc. We've defacto done that for more than a year. Some progress has resulted, but not enough. I will be helping fix ports and I hope others do as well. It's worth noting that a switchable compiler isn't a magic bullet. Many ports will need to be patched to support a compiler other than /usr/bin/cc or /usr/bin/gcc. -- Brooks pgpboAZPyAwWg.pgp Description: PGP signature
Re: Clang as default compiler November 4th
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 FreeBSD > > 10.0 with Clang as the default compiler on i386 and amd64 platforms. To > > this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 > > platforms on November 4th. > > > > What does the mean to you? > > > > * When you build world after the default is changed /usr/bin/cc, cpp, and > >c++ will be links to clang. > > > > * This means the initial phase of buildworld and "old style" kernel > >compilation will use clang instead of gcc. This is known to work. > > > > * It also means that ports will build with clang by default. A major > >of ports work, but a significant number are broken or blocked by > >broken ports. For more information see: > > http://wiki.freebsd.org/PortsAndClang > > > > What issues remain? > > > > * The gcc->clang transition currently requires setting CC, CXX, and CPP > >in addition to WITH_CLANG_IS_CC. I will post a patch to toolchain@ > >to address this shortly. > > > > * Ports compiler selection infrastructure is still under development. > > > > * Some ports could build with clang with appropriate tweaks. > > > > What can you do to help? > > > > * Switch (some of) your systems. Early adoption can help us find bugs. > > > > * Fix ports to build with clang. If you don't have a clang system, you > >can use the CLANG/amd64 or CLANG/i386 build environments on > >redports.org. > > > > tl;dr: Clang will become the default compiler for x86 architectures on > > 2012-11-04 > > There was a chorus of voices talking about ports already. My POV > is that suggesting to 'fix remaining ports to work with clang' is > just a nonsense. You are proposing to fork the development of all the > programs which do not compile with clang. Often, upstream developers > do not care about clang at all since it not being default compiler in > Debian/Fedora/Whatever Linux. The project simply do not have resources > to maintain the fork of 20K programs. I may have phrased the above poorly, but in most cases I'd be happy with using USE_GCC as a solution, but to the extent that port maintainers can fix their ports to build with clang, that's a good thing. Having a deadline will help focus efforts towards finding the right fix for the most important ports in a timely manner. If we near the deadline and find that we need a few more weeks, nothing prevents us from slipping the date a bit. > Another issue with the switch, which seems to be not only not addressed, > but even not talked about, is the performance impact of the change. I > do not remember any measurements, whatever silly they could be, of the > performance change by the compiler switch. We often have serious and > argumented push-back for kernel changes that give as low as 2-3% of > the speed hit. What are the numbers for clang change, any numbers ? Florian Smeets (flo) did one round of benchmarks back in June with sysbench/mysql. There is a small but measurable slowdown both with world compiled with clang and with mysql compiled with clang. You can see the results on the last page of this document: http://people.freebsd.org/~flo/perf.pdf The total impacts are on the order of 1-2%. That's more than I'd like and I expect some pushback, but I feel it is in the range of acceptable code debt to take on to accomplish a multi-year project goal. -- Brooks pgpX5cC5yNg9i.pgp Description: PGP signature
Re: Clang as default compiler November 4th
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 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 platforms. To > > this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 > > platforms on November 4th. > > Just to be clear, this change will only apply to 10-current, 10.0-R and > higher-numbered releases and branches, correct? That is, it won't apply > to RELENG_9 and earlier? Yes. We have no current plans to change the default on older branches. I do plan to merge changes that make it easier for users to choose clang as their base system compiler on 9-STABLE, but changing the compiler would be a terrible idea. -- Brooks pgpOyKJ8LwQzO.pgp Description: PGP signature
Re: improving bootstrapping of WITH_CLANG_IS_CC
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 major redesign.
>
> Due to other $LIFE happening, I just scanned the patch, but I really like it.
>
> I'd also propose a COMPILER_VERSION variable be reserved so that can be set
> so that variations in compiler versions can be comprehended in the tree to
> allow easier external toolchain support as well. I have no impl for this
> yet, but just thought I'd put a bug in people's ear.
I think we'll likely want something like or a COMPILER_FEATURES
variable eventually. For the moment I'm avoiding implementing it to
avoid the problems associated with generalizing from no examples.
One of the ideas we talked about at the devsummit was allowing external
toolchains to provide a makefile to drive things like CFLAGS for WARNS.
I think this would be a very good approach since it could allow a much
broader range of compilers without necessarily requiring FreeBSD
developers to know about all the possible variants.
-- Brooks
pgpfxPX8Zwjq2.pgp
Description: PGP signature
Re: improving bootstrapping of WITH_CLANG_IS_CC
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 pgpKVIZxGLt7t.pgp Description: PGP signature
Re: Clang as default compiler November 4th
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 performed on FreeBSD > > > for floating point generated by clang. Other than the limited > > > testing that I've done, it appears that the answer is 'no'. > > > > > > > We have src/tools/tests/testfloat and src/tools/regression/lib/msun. I > > know nothing about the former (just noticed it for the first time). The > > latter I think is a set of correctness tests rather than performance > > tests. > > It's quite clear that the clang proponent have not tried > to run src/tools/regression/lib/msun. > > % setenv CC clang > % make |& grep warning | wc -l > 1354 > % make clean > % make |& tee make.log > % head -20 make.log > clang -O2 -pipe -march=opteron -O0 -lm test-cexp.c -o test-cexp > test-cexp.c:49:14: warning: pragma STDC FENV_ACCESS ON is not supported, > ignoring pragma [-Wunknown-pragmas] > #pragma STDC FENV_ACCESSON > ^ > test-cexp.c:183:2: warning: expression result unused [-Wunused-value] > testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1); > ^~~ > test-cexp.c:98:7: note: expanded from macro 'testall' > test(cexp, x, result, exceptmask, excepts, checksign); \ > ^ > test-cexp.c:87:11: note: expanded from macro 'test' > assert(((func), fetestexcept(exceptmask) == (excepts)));\ > ^ > /usr/include/assert.h:54:21: note: expanded from macro 'assert' > #define assert(e) ((e) ? (void)0 : __assert(__func__, __FILE__, \ > ^ > test-cexp.c:183:2: warning: expression result unused [-Wunused-value] > testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1); > ^~~ > test-cexp.c:99:7: note: expanded from macro 'testall' > > % tail -20 make.log > test-trig.c:69:11: note: expanded from macro 'test' > assert(((func), fetestexcept(exceptmask) == (excepts)));\ > ^ > /usr/include/assert.h:54:21: note: expanded from macro 'assert' > #define assert(e) ((e) ? (void)0 : __assert(__func__, __FILE__, \ > ^ > 74 warnings generated. > clang -O2 -pipe -march=opteron -O0 -lm test-fenv.c -o test-fenv > test-fenv.c:82:14: warning: pragma STDC FENV_ACCESS ON is not supported, > ignoring pragma [-Wunknown-pragmas] > #pragma STDC FENV_ACCESS ON > ^ > 1 warning generated. > for p in test-cexp test-conj test-csqrt test-ctrig test-exponential test-fma > test-fmaxmin test-ilogb test-invtrig test-logarithm test-lrint test-lround > test-nan test-nearbyint test-next test-rem test-trig test-fenv; do > /usr/src/tools/regression/lib/msun/$p; done > Assertion failed: (((cexp), fetestexcept((0x04 | 0x20 | 0x01 | 0x08 | 0x10)) > == (0))), function test_nan, file test-cexp.c, line 211. > 1..7 > ok 1 - cexp zero > Abort trap (core dumped) > *** [tests] Error code 134 > > Stop in /usr/src/tools/regression/lib/msun. Prompted by this post, I did a bit of testing and it looks like we have two classes of failures that need to be investigated. First, some tests are failing with a gcc compiled world and clang compiled test code. They seem to mostly be unexpected fp exception state when testing with NaNs. I suspect that someone more knowledgeable in this area could come up with a reduced test case and explication of what clang is doing wrong pretty quickly. The second class is tests that fail when libm is compiled using clang. I've not investigate those at all. I'd tend to guess that we have a wider range of issues there. This is clearly an area we need more focus on before a switch to clang. To a point I would be OK with it delaying the switch to work these issues, but as with C99 long double support we can't let the quest for perfection delay us indefinitely. -- Brooks pgpZPRfhJu5W1.pgp Description: PGP signature
enabling libc++ by default when building with clang
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 question is, when do we want to throw this switch? Do we do it
now so people using clang start using it sooner or do we wait until
we've switched the default compiler and things have settled a bit?
I suspect that we'll want to wait, but I'm curious what others think.
-- Brooks
Index: share/mk/bsd.own.mk
===
--- share/mk/bsd.own.mk (revision 240466)
+++ share/mk/bsd.own.mk (working copy)
@@ -432,7 +432,6 @@
ICONV \
IDEA \
INSTALL_AS_USER \
-LIBCPLUSPLUS \
NAND \
OFED \
SHARED_TOOLCHAIN
@@ -642,6 +641,33 @@
.endif
.endfor
+#
+# MK_* options that default to on if the compiler is clang.
+#
+.include
+.for var in \
+LIBCPLUSPLUS
+.if defined(WITH_${var}) && defined(WITHOUT_${var})
+.error WITH_${var} and WITHOUT_${var} can't both be set.
+.endif
+.if defined(MK_${var})
+.error MK_${var} can't be set by a user.
+.endif
+.if ${COMPILER_TYPE} == "clang"
+.if defined(WITHOUT_${var})
+MK_${var}:=no
+.else
+MK_${var}:=yes
+.endif
+.else
+.if defined(WITH_${var})
+MK_${var}:=yes
+.else
+MK_${var}:=no
+.endif
+.endif
+.endfor
+
.if ${MK_CTF} != "no"
CTFCONVERT_CMD=${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
.elif defined(MAKE_VERSION) && ${MAKE_VERSION} >= 520300
pgpPYZSlZ2AYM.pgp
Description: PGP signature
Re: enabling libc++ by default when building with clang
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
> > 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 question is, when do we want to throw this switch? Do we do it
> > now so people using clang start using it sooner or do we wait until
> > we've switched the default compiler and things have settled a bit?
> >
> > I suspect that we'll want to wait, but I'm curious what others think.
>
> Is the compiler type set to be the host's build, or the target's?
It's the target's compiler unless you do a make manually in a portion
of the tree. This means that if you do "make -DWITH_CLANG_IS_CC
buildworld" with this patch that you get libc++ even on a 9-STABLE
system.
An alternative approach here would to enhance bsd.compiler.mk to have a
COMPILER_FEATURES variable and key off of a feature named something like
"c++11". We'll certainly want to do something like that in the future
to support external compilers with varying features.
-- Brooks
>
> Warner
>
> > -- Brooks
> >
> > Index: share/mk/bsd.own.mk
> > ===
> > --- share/mk/bsd.own.mk (revision 240466)
> > +++ share/mk/bsd.own.mk (working copy)
> > @@ -432,7 +432,6 @@
> > ICONV \
> > IDEA \
> > INSTALL_AS_USER \
> > -LIBCPLUSPLUS \
> > NAND \
> > OFED \
> > SHARED_TOOLCHAIN
> > @@ -642,6 +641,33 @@
> > .endif
> > .endfor
> >
> > +#
> > +# MK_* options that default to on if the compiler is clang.
> > +#
> > +.include
> > +.for var in \
> > +LIBCPLUSPLUS
> > +.if defined(WITH_${var}) && defined(WITHOUT_${var})
> > +.error WITH_${var} and WITHOUT_${var} can't both be set.
> > +.endif
> > +.if defined(MK_${var})
> > +.error MK_${var} can't be set by a user.
> > +.endif
> > +.if ${COMPILER_TYPE} == "clang"
> > +.if defined(WITHOUT_${var})
> > +MK_${var}:=no
> > +.else
> > +MK_${var}:=yes
> > +.endif
> > +.else
> > +.if defined(WITH_${var})
> > +MK_${var}:=yes
> > +.else
> > +MK_${var}:=no
> > +.endif
> > +.endif
> > +.endfor
> > +
> > .if ${MK_CTF} != "no"
> > CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
> > .elif defined(MAKE_VERSION) && ${MAKE_VERSION} >= 520300
>
pgpHE5LAVYQ8B.pgp
Description: PGP signature
Re: enabling libc++ by default when building with clang
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 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 question is, when do we want to throw this switch? Do we do it > > now so people using clang start using it sooner or do we wait until > > we've switched the default compiler and things have settled a bit? > > Well, building libc++ does not mean automatically using it. What is the > use case for only building (and installing) libc++, but not linking it > to anything? Just so people could build something with it later on? For now it's really so that people can start testing it without having to tweak more switches. From that perspective it probably makes sense to throw the switch sooner so it's readily available for people who want to start testing it. > In any case, I have been building libc++ for a long time now, and also > did some commits left and right to be able to actually use it for the > base system, e.g. all C++ programs in my installations are already > linked to libc++ (dynamically or statically). I have seen no problems > at all, and I am even working on a WITHOUT_LIBSTDCPLUSPLUS option. :) > > I think the end goal should be to enable building and using libc++ with > one switch. And sooner or later, to make that the default. Then > FreeBSD will finally be able to use C++0x and C++11 features natively. It seems to me that installed, but not used by default is a useful transition state since it reduces the number of knobs required to try it out. If it turns out that other people's experiences match yours then we'll be a in a good position to flip the default linkage switch as well. -- Brooks pgp0IokjZ4iBd.pgp Description: PGP signature
Re: gcc46 --version incompatible with bsd.compiler.mk
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 confuses bsd.compiler.mk.
Alternatively I could alter bsd.compiler.mk to accept gcc[1-9][0-9] as
gcc. You could also set COMPILER_TYPE to override the check entirely.
The end state that got proposed at the Cambridge devsummit was that
external toolchains would provide a makefile that bsd.compiler.mk could
include that would handle this. An example implementation would be to
add something like the following to the top of bsd.compiler.mk:
.if defined(TOOLCHAIN_MK) && exists(${TOOLCHAIN_MK})
.include ${TOOLCHAIN_MK}
.endif
You could then point TOOLCHAIN_MK to a file that might look something
like (I'm not sure the CC assignments would actually work here, but you
get the idea):
CC=gcc46
CXX=g++46
CPP=cpp46
COMPILER_TYPE=gcc
COMPILER_FEATURES=
-- Brooks
pgpHrzhgocT7b.pgp
Description: PGP signature
Re: LLVM Image Activator
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 Belousov wrote: > > >>> On Sun, Jan 13, 2013 at 12:41:09PM +0100, Ed Schouten wrote: > > Hi Kostik, > > > > 2013/1/7 Konstantin Belousov : > > > I still do remember the buzz about the binary format 0xCAFEBABE, which > > > AFAIR gained image activator support on several OSes, to be garbage > > > collected. > > > > Maybe it would then be a good idea then to add some kind of general > > purpose remapping imgact? Example: > > > > /etc/imgacttab: > > > > cafebabe /usr/local/bin/java > > cffaedfe /usr/local/bin/osx_emulator > > 4243c0de /usr/bin/lli > > > > That way we still give people the freedom to play around with mapping > > their own executable formats, but don't need to maintain a bunch of > > imgacts. > > >>> > > >>> A generic module that could be somewhat customized at runtime to map > > >>> offset+signature into the shebang path could be a possibility indeed. > > >>> I strongly prefer to have it as module and not enabled by default. > > >>> > > >>> Asking Nathan for writing the thing is too much, IMHO, esp. in > > >>> the response to the 50-lines hack. > > >>> > > >> > > >> I think this is a good idea, since it both prevents a profusion of > > >> similar activators and works nicely in jails and similar environments. I > > >> probably won't write it quickly, but it should not take more than about > > >> 50 lines, so I can't imagine it will be that bad. There are some > > >> complications with this kind of design from the things in the XXX > > >> comment in imgact_llvm.c about handling argv[0] that I need to think > > >> some more about. > > > Great. I do not believe in the 50 lines, but I am happy that you want > > > to work this out. > > > > > >> > > >> Why are you opposed to having it there by default? I think it's actually > > >> quite important that it be there by default. Having it not "standard" > > >> would be fine, but it should at least be in GENERIC. There are minimal > > >> security risks since it just munges begin_argv and doesn't even load the > > >> executable and it's little enough code that there should not be any > > >> kernel bloat to speak of. If things like this aren't enabled by default, > > >> no one can depend on them being there, no one will use it, and the point > > >> is entirely lost. > > > All image activators demonstrated a constant stream of security holes. > > > Even our ELF activator, and I was guilty there too. > > > > > > I definitely do not fight over the inclusion of the proposed activator > > > into GENERIC, but do insist on the config option + module. > > > > > > > OK, that sounds like a plan then. I'll try to code up something > > configurable in the next couple weeks, unless someone else beats me to it. > > I'll point out that file already has the magic (pun intended) that we > are looking for, though I do realize that the code might be a bit much > to import.. As someone who recently stuffed libmagic into a very constrained sandbox environment, I can safely assert that you don't want to go there. The code isn't written in a way that would make this easy and I definitely wouldn't want it in the kernel. -- Brooks pgp07tnkSUC1K.pgp Description: PGP signature
Re: [RFC] [Optionally] build tests with buildworld
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 > modified), which allows me to build and install various tests on my > git branch like the example ATF tests I produced, pjdfstest, some of > the prove tests from tools/regression, etc (there are other > outstanding changes, but this was the key one that I need feedback on > just to be safe). I don't understand way you don't use WITH_TESTS processed through bsd.own.mk. You'd presumably have to add it to the list of supported NO_* options for the bootstrap case, but that's trivial. Then you use could use normal MK_* variables. That would also let you use WITH(OUT)_TESTS in individual directories and they would always work. At a glance using WITHOUT_TESTS and NO_TEST internally would simplify some of the special cases in your patch. On a side note, I like the HMAKE change independent of the rest of the patch. -- Brooks pgpXu3y5eg2U7.pgp Description: PGP signature
Re: [RFC] [Optionally] build tests with buildworld
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:
> >>> 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
> >>> modified), which allows me to build and install various tests on my
> >>> git branch like the example ATF tests I produced, pjdfstest, some of
> >>> the prove tests from tools/regression, etc (there are other
> >>> outstanding changes, but this was the key one that I need feedback on
> >>> just to be safe).
> >>
> >> I don't understand way you don't use WITH_TESTS processed
> >> through bsd.own.mk. You'd presumably have to add it to the list of
> >> supported NO_* options for the bootstrap case, but that's trivial. Then
> >> you use could use normal MK_* variables. That would also let you use
> >> WITH(OUT)_TESTS in individual directories and they would always work.
> >>
> >> At a glance using WITHOUT_TESTS and NO_TEST internally would simplify
> >> some of the special cases in your patch.
> >
> > This is something that I considered, but I wasn't sure that it was the best
> > route to go about things because I thought we were doing away/had done away
> > with most of the NO_* knobs (and unfortunately one cannot mix and match
> > WITH_* and WITHOUT_* because they're considered contradictory according to
> > bsd.own.mk -- something that Simon has debated against having in the past).
> >
> > I'm all for doing that though because that would simplify things greatly
> > from an end-user perspective.
>
> Hi Brooks!
> Does this look ok? Most of the MK_TESTS logic has been shoved into
> bsd.own.mk and NO_TESTS is sprinkled around Makefile.inc1 as recommended.
> Thanks!
> -Garrett
The functional parts seem fine. Some comments below.
-- Brooks
> Index: Makefile.inc1
> ===
> --- Makefile.inc1 (revision 249833)
> +++ Makefile.inc1 (working copy)
> @@ -91,6 +91,9 @@
> .if ${MK_OFED} != "no"
> SUBDIR+=contrib/ofed
> .endif
> +.if ${MK_TESTS} != "no"
> +SUBDIR+=tests
> +.endif
> #
> # We must do etc/ last for install/distribute to work.
> #
> @@ -253,7 +256,8 @@
> SSP_CFLAGS= \
> -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN \
> -DNO_PIC -DNO_PROFILE -DNO_SHARED \
> - -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD
> + -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD \
> + -DNO_TESTS \
The trailing backslash may be a good idea, but is inconsistant with all
the Makefiles in the system. If you want to make that change is should
discussed seperately.
>
> # build-tools stage
> TMAKE= MAKEOBJDIRPREFIX=${OBJTREE} \
> @@ -263,12 +267,14 @@
> BOOTSTRAPPING=${OSRELDATE} \
> SSP_CFLAGS= \
> -DNO_LINT \
> - -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD
> + -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD \
> + -DNO_TESTS \
>
> # cross-tools stage
> XMAKE= TOOLS_PREFIX=${WORLDTMP} ${BMAKE} \
> TARGET=${TARGET} TARGET_ARCH=${TARGET_ARCH} \
> - -DWITHOUT_GDB
> + -DWITHOUT_GDB \
> + -DNO_TESTS \
>
> # world stage
> WMAKEENV=${CROSSENV} \
> @@ -343,7 +349,8 @@
> -DLIBRARIES_ONLY \
> -DNO_CPU_CFLAGS \
> -DNO_CTF \
> - -DNO_LINT
> + -DNO_LINT \
> + -DNO_TESTS \
>
> LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} ${LIB32WMAKEFLAGS} \
> -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO -DWITHOUT_HTML
> @@ -489,7 +496,7 @@
> @echo "--"
> ${_+_}cd ${.CURDIR}; \
> ${WMAKE} -DNO_FSCHG -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT \
> - -DWITHOUT_MAN -DNO_PROFILE libraries
> + -DWITHOUT_MAN -DNO_PROFILE -DNO_TESTS libraries
> _depend:
> @echo
> @echo "--"
> @@ -1734,6 +1741,7 @@
>
Re: Fwd: docs/178286: [PATCH] document the LOCAL_* vars in build(7)
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 don't understand how to write FreeBSD Makefiles... One minor concern I have with this patch is documenting LOCAL_LIB_DIRS. I've not posted to the lists yet, but now that I understand buildworld better, I think I implemented it wrong. It should have required that the directories be also be listed in LOCAL_DIRS. The reason is that you could then have LOCAL_DIRS=foo and LOCAL_LIB_DIRS=foo/lib so you only added one directory to the FreeBSD tree but could still have libs. I feared that someone might have started using this feature which would mean we can't easily change that. Is Isilon using it? -- Brooks ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree
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 > files that build upon each other or depend on sources located in other > sections of the tree; contrib stuff needs to set .PATH appropriately to > point to sources at the top of the tree, sys stuff is riddled with S= in > order to point to where /sys, etc lives, we build upon FreeBSD within an > expected directory structure as well. > I haven't come up with a name, but was wondering if this was a good > idea, and if so does anyone have any outstanding patches for this that can > be pushed into FreeBSD? I'd like to see this. There's a variable for this in NetBSD and I've wanted to do this because it makes code easier to relocate within the tree. -- Brooks pgpnQ1YvWqsLH.pgp Description: PGP signature
Re: clang and scanbuild
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 that we can build this in > > > FreeBSD instead of checking out llvm source? > > > > You can already run the analyzers with the clang executable in base, > > unless you built your world using WITHOUT_CLANG_FULL. You do need perl > > installed, of course. > > > > > Nice! I did this: > > pkg install lang/clang-devel > export PATH=$PATH:/usr/local/llvm-devel/bin > scan-build cc a.c > > scan-build: Using '/usr/local/llvm-devel/bin/clang' for static analysis > a.c:10:10: warning: Use of memory after it is freed > a[5] ='b'; > ^ > 1 warning generated. > scan-build: 1 bug found. > scan-build: Run 'scan-view /tmp/scan-build-2015-02-16-211517-60875-1' to > examine bug reports. > > scan-view /tmp/scan-build-2015-02-16-211517-60875-1 > Traceback (most recent call last): > File "/usr/local/llvm-devel/bin/scan-view", line 131, in > main() > File "/usr/local/llvm-devel/bin/scan-view", line 128, in main > run(port, options, root) > File "/usr/local/llvm-devel/bin/scan-view", line 57, in run > import ScanView > ImportError: No module named ScanView > > > It looks like some stuff for scan-view is missing from the port. Do you > have any > ideas offhand what is missing? It's not so important, because the > results of scan-build can be opened up in any web browser, independently of > scan-view. You should use the wrappers in /usr/local/bin (e.g. scan-view-devel) as they set up the environment so modules can be found. -- Brooks pgpfvmiPv8KFu.pgp Description: PGP signature
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project)
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 entry, such > as illustrated below. > > $ svnlite diff /usr/ports/lang/clang36 > Index: /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py > === > --- /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py > (revision 381120) > +++ /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py > (working copy) > @@ -3,7 +3,7 @@ > > --- utils/llvm-build/llvmbuild/main.py.orig > +++ utils/llvm-build/llvmbuild/main.py > -@@ -633,7 +633,13 @@ > +@@ -633,7 +633,14 @@ > > # We handle a few special cases of target names here for historical > # reasons, as these are the names configure currently comes up with. > @@ -13,6 +13,7 @@ > + 'i386' : 'X86', > + 'mips' : 'Mips', > + 'powerpc' : 'PowerPC', > ++ 'powerpc64' : 'PowerPC', > + 'sparc64' : 'Sparc', > + 'x86' : 'X86', > 'x86_64' : 'X86', > > > === > Mark Millard > markmi at dsl-only.net > > On 2015-Mar-16, at 11:00 PM, Mark Millard wrote: > > The 2 powerpc (non-64) build attempts for clang 3.6 did not get this problem. > > So this specific problem is powerpc64 specific. > > Bootstrapping powerpc (non-64) clang 3.6 via gcc 4.8.4 (the current lang/gcc) > works fine. (In absence of any c++ port lang/clang36 automatically installed > lang/gcc (currently gcc 4.8.4) in order to bootstrap itself.) > > Bootstrapping powerpc (non-64) clang 3.6 via gcc5 (by having lang/gcc5 > already installed first) still reports an error for not declaring ::sscanf, > just like powerpc64 based on gcc5 for bootstrapping did. > > (This might be llvm/clang making use of only where an include of > would be required to be involved in order to guarantee the :: > (global) declaration/definition. The way the C++ standard (all vintages) is > written gcc 4.8.4 and gcc5 could be this different and both be > valid/conforming.) > > > === > Mark Millard > markmi at dsl-only.net > > On 2015-Mar-16, at 05:04 PM, Mark Millard wrote: > > Basic context (more context details listed later): > > # freebsd-version -ku; uname -ap > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 > 19:23:14 PDT 2015 > root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG > powerpc powerpc64 > > > The problem: > > portmaster -tDK --no-confirm lang/clang36 is how I started the build. > > The error report was after it reported entering the directory: > > /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/lib/Driver/ > > The report was: > > llvm-build: error: invalid native target: 'powerpc64' (not in project) > > > I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. But powerpc64 > likely does. I've not yet tried from a powerpc (non-64) FreeBSD build. > > I'll note that with top -PaSCHopid I watched it compile the PowerPc code > generator software: it shoudl be able to handle PowerPCs fine. > > My guess is a conversion of naming conventions is required someplace: > > FreeBSD using powerpc64 vs. clang using ppc64. (Big endian context.) > > This likely would matter for little endian naming as well (ppc64le on the > clang end of things I expect). > > > > > Context details: > > # svnlite info /usr/ports/lang/clang36 > Path: lang/clang36 > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 > Relative URL: ^/head/lang/clang36 > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: brooks > Last Changed Rev: 380295 > Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) > > It used gcc5 to bootstrap as there was no clang present and that is the only > gcc port installed: > > # svnlite info /usr/ports/lang/gcc5 > Path: lang/gcc5 > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 > Relative URL: ^/head/lang/gcc5 > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: gerald > Last Changed Rev: 380943 > Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) > > # more /etc/make.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > WRKDIRPREFIX=/usr/obj/portswork > #WITH_DEBUG= > MALLOC_PRODUCTION= >
Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
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: > >> > >> about 13 cpu-core-hours running pkg create > >> > >> (Remember: I've been building with WITH_DEBUG= ) Its > >> single-threaded status stands out via elapsed time > >> approximately matching. > >> > >> I'll note that it was somewhat under 6 elapsed hours for > >> staging to have been populated (-j4 with 4 cores present > >> helps for this part). > >> > >> (Of course these elapsed-time figures are rather system > >> dependent, although the ratio might be more stable.) > >> > >> > >> > >> Also interesting was: > >> > >> Installed packages to be REMOVED: > >>llvm40-4.0.0.r4 > >> > >> Number of packages to be removed: 1 > >> > >> The operation will free 49 GiB. > > > > Yes, this is big. But there is no real need to build the llvm ports > > with debug information, unless you want to hack on llvm itself. And > > in that case, you are better served by a Subversion checkout or Git > > clone from upstream instead. > > > > -Dimitry > > FYI: > > Historically unless something extreme like this ends up > involved I build everything using WITH_DEBUG= or explicit > -g's in order to have better information on any failure. > > This is extreme enough that next time I synchronize > /usr/ports and it has a devel/llvm40 update I'll > likely rebuild devel/llvm40 without using WITH_DEBUG= . > I'm more concerned with the time it takes than with > the file system space involved. In the case of LLVM, enabling debug builds does a LOT more than adding symbols. It's much more like enabling WITNESS and INVARIANTS in your kernel, except that the performance of the resulting binary is much worse than a WITNESS kernel (more like 10x slowdown). As Dimitry points out, these builds are of questionable value in ports so garbage collecting the knob might be the sensable thing to do. -- Brooks signature.asc Description: PGP signature
Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)
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: > >>> > >>> Installed packages to be REMOVED: > >>> llvm40-4.0.0.r4 > >>> > >>> Number of packages to be removed: 1 > >>> > >>> The operation will free 49 GiB. > >> > >> Yes, this is big. But there is no real need to build the llvm ports > >> with debug information, unless you want to hack on llvm itself. > > > > Cc'ing jmd@ and rezny@. > > > > I've been watching increasing size of our LLVM packages with increasing > > worry. This is from my tinderbox cache: > > > > $ % env LANG=C ls -lh llvm3* > > -rw-r--r-- 1 root wheel17M Jan 29 2016 llvm35-3.5.2_1.txz > > -rw-r--r-- 1 root wheel18M Mar 7 2016 llvm36-3.6.2_2.txz > > -rw-r--r-- 1 root wheel27M Feb 28 01:05 llvm37-3.7.1_4.txz > > -rw-r--r-- 1 root wheel 207M Jan 19 18:20 llvm38-3.8.1_5.txz > > -rw-r--r-- 1 root wheel 244M Mar 23 16:42 llvm39-3.9.1_2.txz > > > > Dimitry, do you know what had causes such a huge bump in 37 -> 38? > > Yes, up to llvm37, the ports were split in devel/llvmXY and lang/clangXY > parts, with separate ports for e.g. compiler-rt and other LLVM projects. It's mostly that we build both shared and static libraries. llvm37 merged clang and llvm (with a clang37 metaport). Dynamic builds were broken for a while too which blew up program size. > > They take lots of time to build and package. And given that llvm > > is indirect dependency of any X11-related port, it pessimises their > > build times as well (devel/libclc now requires devel/llvm40 after > > r437268). > > The previous split looks pretty hard to maintain, so that is most likely > the reason for combining all components in one port after 3.8. > Unfortunately the side effect is that it is way less granular. I kept it up for several revisions past when it was desupported, but it's absolutly impossible with the cmake infrastructure unless we want want to build all of LLVM four times to get clang, llvm, lldb, and lld. I'm pretty sure that would case more complaints. :) > If we ever get infrastructure for generating multiple packages out of > one port, the devel/llvm* ports are very good candidates. :) Very much so. > > With 49 GiB llvm40, I guess I won't be able to build-test post as my > > hardware would just not be capable enough. > > As said, this is because of WITH_DEBUG. Don't use that for the llvm > ports, for now. It will also allow you to build them with much less RAM > in the machine: especially linking can take multiple GB when debuginfo > is enabled, and optimization is off. I'm looking into improving WITH_DEBUG. -- Brooks P.S. Somewhat off topice, but related. FAIR WARNING: the days of self-hosted 32-bit systems are numbered. Switching to lld from our ancient BFD linker will probably buy us some time, but I'd be surprised if you will be able to build LLVM+CLANG with a 2GB address space in 5 years. The sooner people make their peace with this, the better. signature.asc Description: PGP signature
Re: svn commit: r437976 - in head/devel: . xtoolchain-llvm-devel xtoolchain-llvm-devel/files xtoolchain-llvm40
I've added new xtoolchain ports for llvm. Unlike the
-xtoolchain-gcc ports, they use LLVM's native cross build support
so there is a single one for each usable LLVM version. They use clang
and lld for compilation and linking. It's probably feasible to add
versions that use binutils, but I'll let someone else explore that
space. My results so far:
llvm40 builds i386, amd64, and arm64 with caveats. llvm-devel build
arm64, but amd64 is currently failing and I've not tested i386.
For i386, modules don't link so buildkernel requires -DNO_MODULES. For
arm64, 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 Revision: 437976
> URL: https://svnweb.freebsd.org/changeset/ports/437976
>
> Log:
> Add experimental xtoolchain ports for llvm-devel and llvm40.
>
> With an appropriate port installed, in principle you can build a cross
> world and/or kernel without a bootstrap compiler or binutils with:
>
> make CROSS_TOOLCHAIN=llvm40 TARGET=arm64 buildworld buildkernel
>
> In practice, this only has a chance of working on platforms with solid
> LLD support. At the moment I've had some success with i386, amd64, and
> arm64.
>
> Sponsored by: DARPA, AFRL
>
> Added:
> head/devel/xtoolchain-llvm-devel/
> - copied from r437962, head/devel/powerpc64-xtoolchain-gcc/
> head/devel/xtoolchain-llvm40/
> head/devel/xtoolchain-llvm40/Makefile (contents, props changed)
> Modified:
> head/devel/Makefile
> head/devel/xtoolchain-llvm-devel/Makefile
> head/devel/xtoolchain-llvm-devel/files/xtoolchain.mk.in
>
> Modified: head/devel/Makefile
> ==
> --- head/devel/Makefile Fri Apr 7 23:20:31 2017(r437975)
> +++ head/devel/Makefile Sat Apr 8 00:13:58 2017(r437976)
> @@ -5817,6 +5817,8 @@
> SUBDIR += xparam
> SUBDIR += xsd
> SUBDIR += xtl
> +SUBDIR += xtoolchain-llvm-devel
> +SUBDIR += xtoolchain-llvm40
> SUBDIR += xwpe
> SUBDIR += xxgdb
> SUBDIR += xxhash
>
> Modified: head/devel/xtoolchain-llvm-devel/Makefile
> ==
> --- head/devel/powerpc64-xtoolchain-gcc/Makefile Fri Apr 7 22:32:01
> 2017(r437962)
> +++ head/devel/xtoolchain-llvm-devel/Makefile Sat Apr 8 00:13:58 2017
> (r437976)
> @@ -1,43 +1,47 @@
> # $FreeBSD$
>
> PORTNAME=xtoolchain
> -PORTVERSION= 0.2
> +PORTVERSION= 0.1
> CATEGORIES= devel
> MASTER_SITES=# none
> DISTFILES= # none
> -PKGNAMEPREFIX?= powerpc64-
> -PKGNAMESUFFIX?= -gcc
> +PKGNAMESUFFIX?= -llvm${LLVM_SUFFIX}
>
> -MAINTAINER?= b...@freebsd.org
> +MAINTAINER?= bro...@freebsd.org
> COMMENT= Pre seeded toolchain to cross build FreeBSD base
>
> +LLVM_SUFFIX?=-devel
> +
> NO_BUILD=yes
>
> -.if ${PKGNAMEPREFIX} == "amd64-"
> -TOOLCHAIN_PREFIX=x86_64-
> -.else
> -TOOLCHAIN_PREFIX=${PKGNAMEPREFIX}
> -.endif
> -XCC?=${TOOLCHAIN_PREFIX}unknown-${OPSYS:tl}${OSREL}-gcc
> -XCXX?= ${TOOLCHAIN_PREFIX}unknown-${OPSYS:tl}${OSREL}-g++
> -XCPP?= ${TOOLCHAIN_PREFIX}unknown-${OPSYS:tl}${OSREL}-cpp
> -X_COMPILER_TYPE?=${PKGNAMESUFFIX:C/-//g}
> +XCC?=clang${LLVM_SUFFIX}
> +XCXX?= clang++${LLVM_SUFFIX}
> +XCPP?= clang-cpp${LLVM_SUFFIX}
> +XLD?=${LOCALBASE}/llvm${LLVM_SUFFIX}/bin/ld.lld
> +X_COMPILER_TYPE?=clang
>
> -RUN_DEPENDS?=${XCC}:devel/${PKGNAMEPREFIX}${X_COMPILER_TYPE}
> +RUN_DEPENDS?=${XCC}:devel/llvm${LLVM_SUFFIX}
>
> SUB_FILES= xtoolchain.mk
> -SUB_LIST=TARGETARCH=${TOOLCHAIN_PREFIX:C/-//g} \
> - OPSYS=${OPSYS:tl} \
> - XCC=${XCC} \
> +SUB_LIST=XCC=${XCC} \
> XCXX=${XCXX} \
> XCPP=${XCPP} \
> + XLD=${XLD} \
> X_COMPILER_TYPE=${X_COMPILER_TYPE}
>
> -PLIST_FILES= share/toolchains/${PKGNAMEPREFIX}${X_COMPILER_TYPE}.mk
> +PLIST_FILES= share/toolchains/llvm${LLVM_SUFFIX}.mk \
> + llvm${LLVM_SUFFIX}/bin/ld
>
> do-install:
> @${MKDIR} ${STAGEDIR}${PREFIX}/share/toolchains/
> @${INSTALL_DATA} ${WRKDIR}/xtoolchain.mk \
> -
> ${STAGEDIR}${PREFIX}/share/toolchains/${PKGNAMEPREFIX}${X_COMPILER_TYPE}.mk
> + ${
Re: [Bug 223383] pathconf querying for posix_falloc not supported on freebsd [devel/llvm*'s lld's are also broken by this for zfs and need updating]
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 > > > > --- Comment #7 from commit-h...@freebsd.org --- > > A commit references this bug: > > > > Author: emaste > > Date: Wed Nov 8 00:39:04 UTC 2017 > > New revision: 325523 > > URL: https://svnweb.freebsd.org/changeset/base/325523 > > > > Log: > > MFC r325420: lld: accept EINVAL to indicate posix_fallocate is unsupported > > > > As of r325320 posix_fallocate on a ZFS filesystem returns EINVAL to > > indicate that the operation is not supported. (I think this is a strange > > choice of errno on the part of POSIX.) > > > > PR: 223383, 223440 > > Reported by: Mark Millard > > Sponsored by: The FreeBSD Foundation > > > > Changes: > > _U stable/11/ > > stable/11/contrib/llvm/lib/Support/Unix/Path.inc > > > > -- > > You are receiving this mail because: > > You are on the CC list for the bug. > > [Context a zfs file system.] > > From /usr/src/UPDATING: > > 20171106: > The naive and non-compliant support of posix_fallocate(2) in ZFS > has been removed as of r325320. The system call now returns EINVAL > when used on a ZFS file. Although the new behavior complies with the > standard, some consumers are not prepared to cope with it. > One known victim is lld prior to r325420. > > > The issue is not limited to the system clang's > associated lld. > > Here is an attempt to use clang++50, implicitly using > its associated lld: > > # clang++50 -v exception_test.cc > clang version 5.0.0 (tags/RELEASE_500/final) > Target: x86_64-portbld-freebsd12.0 > Thread model: posix > InstalledDir: /usr/local/llvm50/bin > "/usr/local/llvm50/bin/clang-5.0" -cc1 -triple x86_64-portbld-freebsd12.0 > -emit-obj -mrelax-all -disable-free -main-file-name exception_test.cc > -mrelocation-model static -mthread-model posix -mdisable-fp-elim > -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v > -dwarf-column-info -debugger-tuning=gdb -resource-dir > /usr/local/llvm50/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 > -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit 19 > -fmessage-length 200 -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions > -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/exception_test-baadc9.o > -x c++ exception_test.cc > clang -cc1 version 5.0.0 based upon LLVM 5.0.0 default target > x86_64-portbld-freebsd12.0 > #include "..." search starts here: > #include <...> search starts here: > /usr/include/c++/v1 > /usr/local/llvm50/lib/clang/5.0.0/include > /usr/include > End of search list. > "/usr/local/llvm50/bin/ld" --eh-frame-hdr -dynamic-linker > /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o a.out > /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib > /tmp/exception_test-baadc9.o -lc++ -lm -lgcc --as-needed -lgcc_s > --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o > /usr/lib/crtn.o > /usr/local/llvm50/bin/ld: error: cannot open output file a.out: Invalid > argument > clang-5.0: error: linker command failed with exit code 1 (use -v to see > invocation) > > > https://svnweb.freebsd.org/ports/head/devel/?dir_pagestart=1000 > > does not yet suggest updates to devel/llvm* 's for > the issue. > > === > Mark Millard > markmi at dsl-only.net > signature.asc Description: PGP signature
splitting libc -> libc + libsys and static 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.a into libc.a? Do we try to teach all the compilers to add -lsys? I'm pretty sure we don't modify all the ports that statically link programs. Is there some easy approach I'm missing? -- Brooks signature.asc Description: PGP signature
Re: splitting libc -> libc + libsys and static linking
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, > > 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.a into libc.a? Do we try to teach all the > > compilers to add -lsys? I'm pretty sure we don't modify all the ports > > that statically link programs. Is there some easy approach I'm missing? > > I'm curious about the reasoning behind this change. Could you explain > in more detail why you'd like to create a libsys? In CheriBSD I use something like this to let me use the same libc inside and outside sandboxes while varying the syscall implementation. Ali is (IIRC) using it in a record and playback framework. It could potentially let us link a libsys_pic.a into libthr.so and rtld to eliminate the need for syscall(2). It could also ease experimentation with alternative syscall invocation methods (e.g. I've got a branch of CheriBSD where the ability to make a given syscall is controlled by possession of an unforgable token.) Having a clear interface in a separate library makes it easier to know what to replace and gives a clear place to do it. -- Brooks signature.asc Description: PGP signature
Re: Tool Chain Migration: objdump users, please test llvm-objdump
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). objdump is a tool to report information > about binary objects (such as headers, symbols, etc.), is not required > as a build tool, and in any case many uses of objdump are better > served by readelf. > > For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is > open to track tasks related to its removal, and users who need GNU > objdump can install an up-to-date version from the ports tree or the > binutils package. > > That said, llvm includes a somewhat equivalent llvm-objdump, and it is > built by default in FreeBSD now. If llvm-objdump's command line option > support and output format is "close enough" to GNU objdump for most > users we may decide to install it as /usr/bin/objdump. Therefore, I > would like to ask users of GNU objdump in FreeBSD to give llvm-objdump > a try. Please let me know if it works for your uses, or describe > deficiencies that you found. I think we've changed our flag us in CheriBSD to accommodate llvm-objdump so at least a few months ago flag compatibility was poor. The output is different, but fine for my uses (producing human readable assembly output). -- Brooks signature.asc Description: PGP signature
Re: svn commit: r339898 - head/lib/libc/amd64/sys
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 ifunc. > > > > Note that this is the first use of ifuncs in our userspace. > > > > Sponsored by: The FreeBSD Foundation > > MFC after:1 month > > > > Deleted: > > head/lib/libc/amd64/sys/amd64_detect_rdfsgsbase.c > > head/lib/libc/amd64/sys/amd64_detect_rdfsgsbase.h > > Modified: > > head/lib/libc/amd64/sys/Makefile.inc > > head/lib/libc/amd64/sys/amd64_get_fsbase.c > > head/lib/libc/amd64/sys/amd64_get_gsbase.c > > head/lib/libc/amd64/sys/amd64_set_fsbase.c > > head/lib/libc/amd64/sys/amd64_set_gsbase.c > > > Using LLVM 7 to build world, fails: > > --- amd64_get_fsbase.o --- > /usr/src/lib/libc/amd64/sys/amd64_get_fsbase.c:60:1: error: ifunc > resolver function must have no parameters > --- amd64_get_gsbase.o --- > /usr/src/lib/libc/amd64/sys/amd64_get_gsbase.c:60:1: error: ifunc > resolver function must have no parameters > DEFINE_UIFUNC(, int, amd64_get_gsbase, (void **), static) > ^ > /usr/local/obj/usr/src/amd64.amd64/tmp/usr/include/x86/ifunc.h:43:44: > note: expanded from macro 'DEFINE_UIFUNC' > --- amd64_get_fsbase.o --- > DEFINE_UIFUNC(, int, amd64_get_fsbase, (void **), static) > ^ > /usr/local/obj/usr/src/amd64.amd64/tmp/usr/include/x86/ifunc.h:43:44: > note: expanded from macro 'DEFINE_UIFUNC' > --- amd64_get_gsbase.o --- > qual ret_type name args __attribute__((ifunc(#name "_resolver"))); \ >^ > --- amd64_get_fsbase.o --- > qual ret_type name args __attribute__((ifunc(#name "_resolver"))); \ >^ > 1 error generated. > --- amd64_get_gsbase.o --- > 1 error generated. > *** [amd64_get_gsbase.o] Error code 1 > > make[4]: stopped in /usr/src/lib/libc > > CI appears green after this commit, so I'm inclined to pin this on yet > another instance of LLVM 7 being stricter than LLVM 6. Backing out this > revision allows the build to continue (successfully). Is this failure with devel/llvm70? It's currently missing the patch required to make this work. https://reviews.freebsd.org/D17709 contains this patch among others. I'll see about getting it applied. -- Brooks signature.asc Description: PGP signature
Re: head -r340287 's /usr/src/Makefile.libcompat still lists various LIB32CPUFLAGS= -target *-unknown-freebsd12.0 (not 13.0)
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
> ===
> --- /usr/src/Makefile.libcompat (revision 340287)
> +++ /usr/src/Makefile.libcompat (working copy)
> @@ -17,7 +17,7 @@
> .if ${WANT_COMPILER_TYPE} == gcc || \
> (defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc)
> .else
> -LIB32CPUFLAGS+= -target x86_64-unknown-freebsd12.0
> +LIB32CPUFLAGS+= -target x86_64-unknown-freebsd13.0
> .endif
> LIB32CPUFLAGS+= -m32
> LIB32WMAKEENV= MACHINE=i386 MACHINE_ARCH=i386 \
> @@ -49,9 +49,9 @@
> .endif
> .else
> .if ${TARGET_ARCH:Mmips64el*} != ""
> -LIB32CPUFLAGS= -target mipsel-unknown-freebsd12.0
> +LIB32CPUFLAGS= -target mipsel-unknown-freebsd13.0
> .else
> -LIB32CPUFLAGS= -target mips-unknown-freebsd12.0
> +LIB32CPUFLAGS= -target mips-unknown-freebsd13.0
> .endif
> .endif
> LIB32CPUFLAGS+= -mabi=32
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
> ___
> freebsd-toolchain@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
>
signature.asc
Description: PGP signature
Re: External GCC Update
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/src.conf. The current patch on
> >>github for this only fixes world and not yet kern.pre.mk and probably
> >>needs the most review if we want to go forward with this route. With
> >>this, I plan to have the base/* packages install suitable files in this
> >>dir that disable build of the src-based components and also set
> >>WITH_BASE_ to make sure 'delete-old' DTRT.
> >
> > Not sure if I like this. Can't src.opts.mk just call `pkg info -e
> > base/binutils` and so forth and use the exit result to adjust the defaults?
>
> That requires src.opts.mk to encode the policy that each package wants to
> enforce rather than letting the package choose the policy it wants to
> enforce. I think we want the latter.
>
> >> The file for base/binutils would be:
> >>
> >> CROSS_BINUTILS_PREFIX=/usr/bin/
> >> WITH_BASE_BINUTILS=yes
> >> WITHOUT_BINUTILS=yes
> >> WITHOUT_LLD_IS_LD=yes
> >>
> >> The file for base/gcc would be:
> >>
> >> XCC=/usr/bin/cc
> >> XCXX=/usr/bin/c++
> >> XCPP=/usr/bin/cpp
> >> X_COMPILER_TYPE=gcc
> >> WITH_BASE_GCC=yes
> >> WITHOUT_GCC=yes
> >> WITHOUT_CLANG_IS_CC=yes
> >
> > I don't like the concept of packages messing with anything related to
> > src.conf. I have a bunch of conditional stuff in mine broken out by
> > ${TARGET_ARCH} and extra config suddenly appearing would break a lot of my
> > cross compiling stuff, even if it is in a separate *.d folder.
> >
> > Seems to me that just influencing src.opts.mk's defaults would be more
> > robust.
>
> Hmm, cross compiling is indeed a bear. My original version of this was to
> have base/gcc install a special 'freebsd-gcc.mk' toolchain file to
> /usr/share/toolchains and modify Makefile.inc1 to use this as the default
> CROSS_TOOLCHAIN if present. I mostly didn't like this because it would be
> a single file that so you can't set separate policy if, for example, some
> arch or install only wanted base/binutils and not base/gcc. On the other
> hand, it had the advantage that setting an explicit CROSS_TOOLCHAIN when you
> are cross compiling would work correctly.
>
> Perhaps I can rework this to use two files in /usr/share/toolchains and have
> Makefile.inc1 explicitly include any files in that directory if
> CROSS_TOOLCHAIN isn't set?
I think I like that option best.
Another way to deal with the two-files issue would be to have a
base/toolchain metaport with options that installs the consolidated file
you want. That mirrors (somewhat) the setup in devel/*xtoolchain*, but
I'm not convinced it won't just lead to confusion.
-- Brooks
signature.asc
Description: PGP signature
Re: add linker option for LIB32 step on PowerPC64
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 > > the LIB32 step. > > Ok - eventual goal should be to have 32- and 64-bit linked with lld, > but I have no objection to an interim step that uses ld.bfd 2.17.50 > for the 32-bit build. Note that there's a goal of removing GCC 4.2.1 > and binutils 2.17.50 (requiring external toolchain for architectures > that have not migrated to clang/lld). If need by, we can add an XLIB32LD. -- Brooks signature.asc Description: PGP signature
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
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-LLVM platforms is that makes sense. -- Brooks On Mon, Aug 05, 2019 at 08:45:31PM -0700, Mark Millard via freebsd-toolchain wrote: > Building math/z3 involves: > > # grep compiler /usr/ports/math/z3/Makefile > USES= compiler:c++11-lang python:2.7,build > > But devel/llvm90 requires math/z3 to have been built before > devel/llvm90 is built: > > # pkg info -d llvm90 > llvm90-9.0.0.r1: > libxml2-2.9.9 > z3-4.8.5_1 > python36-3.6.9 > perl5-5.28.2 > libedit-3.1.20190324,1 > # pkg info -B llvm90 > llvm90-9.0.0.r1: > libpython3.6m.so.1.0 > libedit.so.0 > libz3.so.0 > libxml2.so.2 > > > Hopefully this cycle can be avoided for system > clang to eventually have progressed to clang 9. > (I do not know the details.) > > For architectures still at gcc/g++ 4.2.1, some > alternate c++ tool chain needs to be used to > build libz3.so but the result needs to be > compatible with llvm90 later using the libz3.so's > content. (I do not know the details.) > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > ___ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" > signature.asc Description: PGP signature
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
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 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-LLVM platforms is that makes sense. > > > > -- Brooks > > Okay. > > poudriere-devel automatically built math/z3 because > I'd indicated to build devel/llvm90 . math/z3 was not > previously built: I've never had other use of it. So > my context was not one of an implicit autodetect. The dependency is there because if z3 is installed then the package that is built depends on z3. Thus I had not choice but to add a z3 dependency until I find a way to turn it off. You can either help find a way to disable z3 detection in the cmake infrastructure or turn off LIT. I don't have any use for reports on the effects of commenting out the DEPENDS line. I know what that does. -- Brooks signature.asc Description: PGP signature
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
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
> up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
>
> On 2019-Aug-6, at 20:23, Mark 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:
> >>>
> >>>> 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-LLVM platforms is that makes sense.
> >>>>
> >>>> -- Brooks
> >>>
> >>> Okay.
> >>>
> >>> poudriere-devel automatically built math/z3 because
> >>> I'd indicated to build devel/llvm90 . math/z3 was not
> >>> previously built: I've never had other use of it. So
> >>> my context was not one of an implicit autodetect.
> >>
> >> The dependency is there because if z3 is installed then the package
> >> that is built depends on z3. Thus I had not choice but to add a z3
> >> dependency until I find a way to turn it off. You can either help find
> >> a way to disable z3 detection in the cmake infrastructure or turn off
> >> LIT. I don't have any use for reports on the effects of commenting out
> >> the DEPENDS line. I know what that does.
> >
> >
> > I hope this helps. (I'm not a cmake expert.)
> >
> > llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
> >
> > #if LLVM_WITH_Z3
> >
> > #include
> >
> > namespace {
> > . . .
> > } // end anonymous namespace
> >
> > #endif
> >
> > llvm::SMTSolverRef llvm::CreateZ3Solver() {
> > #if LLVM_WITH_Z3
> > return llvm::make_unique();
> > #else
> > llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild "
> > "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> > false);
> > return nullptr;
> > #endif
> > }
> >
> > (There are other places LLVM_WITH_Z3 is used but the
> > above is suggestive.)
> >
> > Working backwards finds that:
> >
> > /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
> >
> > shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
> >
> > set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
> > solver.")
> >
> > find_package(Z3 4.7.1)
> >
> > if (LLVM_Z3_INSTALL_DIR)
> > if (NOT Z3_FOUND)
> >message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
> > LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
> > endif()
> > endif()
> >
> > set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
> >
> > option(LLVM_ENABLE_Z3_SOLVER
> > "Enable Support for the Z3 constraint solver in LLVM."
> > ${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
> > )
> >
> > if (LLVM_ENABLE_Z3_SOLVER)
> > if (NOT Z3_FOUND)
> >message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3 is
> > not available.")
> > endif()
> >
> > set(LLVM_WITH_Z3 1)
> > endif()
> >
> > if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
> > set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
> > endif()
> >
> >
> > If I read that correctly, LLVM_ENABLE_Z3_SOLVER set directly
> > appears to override the default (that tracks if z3 was found).
>
> I saw a reference to:
>
> diff --git a/llvm/cmake/modules/CrossCompile.cmake
> b/llvm/cmake/modules/CrossCompile.cmake
> index bc3b210f018..0c30b88f80f 100644
> --- a/llvm/cmake/modules/CrossCompile.cmake
> +++ b/llvm/cmake/modules/CrossCompile.cmake
> @@ -53,6 +53,7 @@ function(llvm_create_cross_target_internal target_name
> toolchain buildtype)
> -DLLVM_DEFAULT_TARGET_TRIPLE="${TARGET_TRIPLE}"
> -DLLVM_TARGET_ARCH="${LLVM_TARGET_ARCH}"
>
> -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="${LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN}"
> +-DLLVM_ENABLE_
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
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
> > up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
> >
> > On 2019-Aug-6, at 20:23, Mark 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:
> > >>>
> > >>>> 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-LLVM platforms is that makes sense.
> > >>>>
> > >>>> -- Brooks
> > >>>
> > >>> Okay.
> > >>>
> > >>> poudriere-devel automatically built math/z3 because
> > >>> I'd indicated to build devel/llvm90 . math/z3 was not
> > >>> previously built: I've never had other use of it. So
> > >>> my context was not one of an implicit autodetect.
> > >>
> > >> The dependency is there because if z3 is installed then the package
> > >> that is built depends on z3. Thus I had not choice but to add a z3
> > >> dependency until I find a way to turn it off. You can either help find
> > >> a way to disable z3 detection in the cmake infrastructure or turn off
> > >> LIT. I don't have any use for reports on the effects of commenting out
> > >> the DEPENDS line. I know what that does.
> > >
> > >
> > > I hope this helps. (I'm not a cmake expert.)
> > >
> > > llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
> > >
> > > #if LLVM_WITH_Z3
> > >
> > > #include
> > >
> > > namespace {
> > > . . .
> > > } // end anonymous namespace
> > >
> > > #endif
> > >
> > > llvm::SMTSolverRef llvm::CreateZ3Solver() {
> > > #if LLVM_WITH_Z3
> > > return llvm::make_unique();
> > > #else
> > > llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild
> > > "
> > > "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> > > false);
> > > return nullptr;
> > > #endif
> > > }
> > >
> > > (There are other places LLVM_WITH_Z3 is used but the
> > > above is suggestive.)
> > >
> > > Working backwards finds that:
> > >
> > > /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
> > >
> > > shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
> > >
> > > set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
> > > solver.")
> > >
> > > find_package(Z3 4.7.1)
> > >
> > > if (LLVM_Z3_INSTALL_DIR)
> > > if (NOT Z3_FOUND)
> > >message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
> > > LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
> > > endif()
> > > endif()
> > >
> > > set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
> > >
> > > option(LLVM_ENABLE_Z3_SOLVER
> > > "Enable Support for the Z3 constraint solver in LLVM."
> > > ${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
> > > )
> > >
> > > if (LLVM_ENABLE_Z3_SOLVER)
> > > if (NOT Z3_FOUND)
> > >message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3
> > > is not available.")
> > > endif()
> > >
> > > set(LLVM_WITH_Z3 1)
> > > endif()
> > >
> > > if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
> > > set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
> > > endif()
> > >
> > >
> > > If I read that correctly, LLVM_ENABLE_Z3_SOLVER set directly
> > > appears to override the default (that tracks if z3 was found
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
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:
> >>> [I found something known to be missing in the
> >>> in at least some versions of
> >>> llvm/cmake/modules/CrossCompile.cmake that messes
> >>> up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
> >>>
> >>> On 2019-Aug-6, at 20:23, Mark 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:
> >>>>>>
> >>>>>>> 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-LLVM platforms is that makes sense.
> >>>>>>>
> >>>>>>> -- Brooks
> >>>>>>
> >>>>>> Okay.
> >>>>>>
> >>>>>> poudriere-devel automatically built math/z3 because
> >>>>>> I'd indicated to build devel/llvm90 . math/z3 was not
> >>>>>> previously built: I've never had other use of it. So
> >>>>>> my context was not one of an implicit autodetect.
> >>>>>
> >>>>> The dependency is there because if z3 is installed then the package
> >>>>> that is built depends on z3. Thus I had not choice but to add a z3
> >>>>> dependency until I find a way to turn it off. You can either help find
> >>>>> a way to disable z3 detection in the cmake infrastructure or turn off
> >>>>> LIT. I don't have any use for reports on the effects of commenting out
> >>>>> the DEPENDS line. I know what that does.
> >>>>
> >>>>
> >>>> I hope this helps. (I'm not a cmake expert.)
> >>>>
> >>>> llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
> >>>>
> >>>> #if LLVM_WITH_Z3
> >>>>
> >>>> #include
> >>>>
> >>>> namespace {
> >>>> . . .
> >>>> } // end anonymous namespace
> >>>>
> >>>> #endif
> >>>>
> >>>> llvm::SMTSolverRef llvm::CreateZ3Solver() {
> >>>> #if LLVM_WITH_Z3
> >>>> return llvm::make_unique();
> >>>> #else
> >>>> llvm::report_fatal_error("LLVM was not compiled with Z3 support, rebuild
> >>>> "
> >>>> "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> >>>> false);
> >>>> return nullptr;
> >>>> #endif
> >>>> }
> >>>>
> >>>> (There are other places LLVM_WITH_Z3 is used but the
> >>>> above is suggestive.)
> >>>>
> >>>> Working backwards finds that:
> >>>>
> >>>> /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMakeLists.txt
> >>>>
> >>>> shows LLVM_WITH_Z3 being conditionally set to 1 via . . .
> >>>>
> >>>> set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3
> >>>> solver.")
> >>>>
> >>>> find_package(Z3 4.7.1)
> >>>>
> >>>> if (LLVM_Z3_INSTALL_DIR)
> >>>> if (NOT Z3_FOUND)
> >>>> message(FATAL_ERROR "Z3 >= 4.7.1 has not been found in
> >>>> LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
> >>>> endif()
> >>>> endif()
> >>>>
> >>>> set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
> >>>>
> >>>> option(LLVM_ENABLE_Z3_SOLVER
> >>>> "Enable Support for the Z3 con
Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place
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 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
> >>>>> up the overall handling of LLVM_ENABLE_Z3_SOLVER .]
> >>>>>
> >>>>> On 2019-Aug-6, at 20:23, Mark 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:
> >>>>>>>>
> >>>>>>>>> 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-LLVM platforms is that makes sense.
> >>>>>>>>>
> >>>>>>>>> -- Brooks
> >>>>>>>>
> >>>>>>>> Okay.
> >>>>>>>>
> >>>>>>>> poudriere-devel automatically built math/z3 because
> >>>>>>>> I'd indicated to build devel/llvm90 . math/z3 was not
> >>>>>>>> previously built: I've never had other use of it. So
> >>>>>>>> my context was not one of an implicit autodetect.
> >>>>>>>
> >>>>>>> The dependency is there because if z3 is installed then the package
> >>>>>>> that is built depends on z3. Thus I had not choice but to add a z3
> >>>>>>> dependency until I find a way to turn it off. You can either help
> >>>>>>> find
> >>>>>>> a way to disable z3 detection in the cmake infrastructure or turn off
> >>>>>>> LIT. I don't have any use for reports on the effects of commenting
> >>>>>>> out
> >>>>>>> the DEPENDS line. I know what that does.
> >>>>>>
> >>>>>>
> >>>>>> I hope this helps. (I'm not a cmake expert.)
> >>>>>>
> >>>>>> llvm-9.0.0rc1.src/lib/Support/Z3Solver.cpp does:
> >>>>>>
> >>>>>> #if LLVM_WITH_Z3
> >>>>>>
> >>>>>> #include
> >>>>>>
> >>>>>> namespace {
> >>>>>> . . .
> >>>>>> } // end anonymous namespace
> >>>>>>
> >>>>>> #endif
> >>>>>>
> >>>>>> llvm::SMTSolverRef llvm::CreateZ3Solver() {
> >>>>>> #if LLVM_WITH_Z3
> >>>>>> return llvm::make_unique();
> >>>>>> #else
> >>>>>> llvm::report_fatal_error("LLVM was not compiled with Z3 support,
> >>>>>> rebuild "
> >>>>>> "with -DLLVM_ENABLE_Z3_SOLVER=ON",
> >>>>>> false);
> >>>>>> return nullptr;
> >>>>>> #endif
> >>>>>> }
> >>>>>>
> >>>>>> (There are other places LLVM_WITH_Z3 is used but the
> >>>>>> above is suggestive.)
> >>>>>>
> >>>>>> Working backwards finds that:
> >>>>>>
> >>>>>> /wrkdirs/usr/ports/devel/llvm90/work/llvm-9.0.0rc1.src/CMa
Re: linker not using make.conf
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: linker command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 > > XLD= /usr/local/bin/ld.lld80 being set as well also provides the same error. > XD sets it for all, but XLD is only applicable if a different compiler is > used for ports than kernel and the base. When LD is set, XLD only applies > when it is set as well, but this suggests that XLD is not working correctly > either. > > I have to manually link /usr/bin/ld to /usr/local/bin/ld.lld80 for ports to > build correctly. This is with both make, and with portmaster. > > I built my computer without ld in the base system, and this has worked well. > make.conf should reference the chosen linker without having to manually link > it. Otherwise, LD in make.conf is not working correctly, and gives the > impression that one linker is used, when it's not. This can cause faulty > conclusions and confusion for developers as well, who think one linker is > set, when it's not. > The LD variable only effects the very few cases where the linker is called directly. The linker is almost always run via clang. If you install the xtoolchain-llvm80 port it will install a link from /usr/local/llvm80/bin/ld.lld to /usr/local/llvm80/bin/ld which I think will be sufficient for your use case. -- Brooks signature.asc Description: PGP signature
[Differential] [Accepted] D2338: readelf: avoid division by zero for files with invalid sh_entsize
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 ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Differential] [Updated] D2408: Add ELF Tool Chain's c++filt to the build
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 ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Differential] [Accepted] D2408: Add ELF Tool Chain's c++filt to the build
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 ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Differential] [Commented On] D2338: readelf: avoid division by zero for files with invalid sh_entsize
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-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Differential] [Accepted] D2338: readelf: avoid division by zero for files with invalid sh_entsize
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-list ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Differential] [Accepted] D3175: ar: add -U (unique) option to disable -D (deterministic) mode
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 ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Differential] [Accepted] D3190: ar: enable deterministic mode by default
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 ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
