Re: powerpc64 graphics/mesa-dri build failure in poudriere, system clang's /usr/bin/cc got assert failure: "Target supports vector op, but scalar requires expansion?"
Ralf Wenk writes: > On 2019-05-23, at 12:31 -0700, Mark Millard wrote: > >> On 2019-May-23, at 11:47, Jan Beich wrote: >> >> > Mark Millard writes: >> > >> >> Unfortunately poudiere bulk tar archives of failures do not >> >> catch the /tmp/* material from: >> >> >> >> cc: error: unable to execute command: Abort trap (core dumped) >> >> cc: error: clang frontend command failed due to signal (use -v to see >> >> invocation) >> >> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on >> >> LLVM 8.0.0) >> >> Target: powerpc64-unknown-freebsd13.0 >> >> Thread model: posix >> >> InstalledDir: /usr/bin >> > >> > Do you have the build log? Maybe it's possible to reproduce simply by >> > adding >> > -target powerpc64-unknown-freebsd13.0 while cross-building that particular >> > file >> > using otherwise the same command line options as native build. >> >> I have expanded the poudriere bulk's tar of the failure and rerun the >> command from there. The problem reproduced: >> >> # ls -lTdt /tmp/nir_constant_expressions-9b094e.* >> -rw-r--r-- 1 root wheel11069 May 23 12:08:35 2019 >> /tmp/nir_constant_expressions-9b094e.sh >> -rw-r--r-- 1 root wheel 1951892 May 23 12:08:35 2019 >> /tmp/nir_constant_expressions-9b094e.c >> >> >> So I gzip'd the .c and created: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238082 >> >> with the two files as 2 attachments. > > This looks familiar to me. Is the kernel you are using at r348115 or newer? > > r348115 triggers such kind of "unable to execute" compiler errors on my > system. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238084 Bug 238082 unlike bug 238084 can be reproduced even on amd64 just by running the generated files. ___ 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"
Re: On a powerpc64, system-clang crashes on audio/alsa-lib 's control.lo : "error in backend: A @@ version cannot be undefined"
Dimitry Andric writes: > http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=3bad0a21b4d13d8d10691f382c836897fa7a7cb9 > > You might want to try if that also works for you. Applied in r481945. Let's see what happens. ;) ___ 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"
Re: On a powerpc64, system-clang crashes on audio/alsa-lib 's control.lo : "error in backend: A @@ version cannot be undefined"
Mark Millard writes:
> The following is on a powerpc64 machine (old PowerMac G5 so-called
> "Quad Core") running a personal build of head -r339076 that was
> built via devel/powerpc64-xtoolchain-gcc and such (no gcc 4.2.1).
> The compiler for the port build is system-clang (so clang 6 as cc),
> not used for buildworld buildkernel. [I experiment with more modern
> compilers and toolchains for some powerpc family members.]
[...]
> /bin/sh ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H
> -I. -I../../include -I../../include -I/usr/ports/audio/alsa-lib/files
> -O2 -pipe -g -fno-strict-aliasing -MT control.lo -MD -MP -MF
> .deps/control.Tpo -c -o control.lo control.c
[...]
> fatal error: error in backend: A @@ version cannot be undefined
> cc: error: clang frontend command failed with exit code 70 (use -v to see
> invocation)
> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM
> 6.0.1)
> Target: powerpc64-unknown-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/bin
Looks easy to reproduce on amd64 via -target e.g.,
$ cd /usr/ports/audio/alsa-lib
$ make clean configure
$ cd $(make -V WRKSRC)/src/control
$ ln -s ${SYSDIR:-/usr/src/sys}/powerpc/include /tmp/machine
$ make control.lo CC='cc -target powerpc64-unknown-freebsd12.0 -isystem /tmp'
[...]
fatal error: error in backend: A @@ version cannot be undefined
cc: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
FreeBSD clang version 7.0.0 (tags/RELEASE_700/final 342383) (based on LLVM
7.0.0)
which points to the following conditional
#ifdef __powerpc64__
# define symbol_version(real, name, version) \
__asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@"
#version);\
__asm__ (".symver ." ASM_NAME(#real) ",." ASM_NAME(#name) "@"
#version)
# define default_symbol_version(real, name, version) \
__asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@@"
#version); \
__asm__ (".symver ." ASM_NAME(#real) ",." ASM_NAME(#name) "@@"
#version)
#else
# define symbol_version(real, name, version) \
__asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@" #version)
# define default_symbol_version(real, name, version) \
__asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@@" #version)
#endif
and can be further reduced to
int main()
{
__asm__ (".symver __foo,foo@@FOO");
__asm__ (".symver .__foo,.foo@@FOO");
}
___
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"
Re: Is -march/-mtune=native actually supported on FreeBSD arm* or aarch64?
Jan Beich writes: > Some ports pass -march=native and/or -mtune=native. Both are extensively > documented by GCC for x86. For other architectures some excerpts say > "native" is only supported on Linux (via /proc/cpuinfo). For example, Oops, found a partial answer: https://lists.freebsd.org/pipermail/freebsd-arm/2016-February/013190.html ___ 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"
Is -march/-mtune=native actually supported on FreeBSD arm* or aarch64?
Some ports pass -march=native and/or -mtune=native. Both are extensively
documented by GCC for x86. For other architectures some excerpts say
"native" is only supported on Linux (via /proc/cpuinfo). For example,
$ uname -p
armv6
$ echo 'int main() {}' >a.c
$ clang -march=native a.c
clang: error: the clang compiler does not support '-march=native'
$ clang -mtune=native a.c
$ pkg install -qy gcc7
$ gcc7 -march=native a.c
$ gcc7 -mtune=native a.c
$ uname -p
aarch64
$ echo 'int main() {}' >a.c
$ clang -march=native a.c
clang: error: the clang compiler does not support '-march=native'
$ clang -mtune=native a.c
clang: error: the clang compiler does not support '-mtune=native'
$ pkg install -qy gcc7
$ gcc7 -march=native a.c
$ gcc7 -mtune=native a.c
What's the rationale for Clang vs. GCC difference? Is it safe to run
FreeBSD arm* -mtune=native binaries on CPUs older than build machine?
___
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"
dtrace -G vs. -flto
I'd like to build www/firefox with both DTrace and LTO support. Both
Clang and GCC emit code that dtrace(1) doesn't understand.
$ cat main.c
#include
#include
int main()
{
DTRACE_PROBE(test, foo);
sleep(300);
return 0;
}
$ cat test.d
provider test {
probe foo();
};
$ clang50 -flto -c main.c
$ dtrace -G -s test.d main.o
dtrace: failed to link script test: invalid file type: main.o
$ file main.o
main.o: LLVM IR bitcode
$ gcc7 -flto -c main.c
$ dtrace -G -s test.d main.o
dtrace: failed to link script test: No probe sites found for declared provider
$ file main.o
main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped
--
$ uname -a
FreeBSD ... 12.0-CURRENT #0 r325899M ... amd64
___
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"
Re: FCP-100: armv7 plan
Warner Losh writes: > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > >> Warner Losh writes: >> >> > Greetings, >> > >> > This will serve as 'Last Call' for any objections to the plan to create >> an >> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. >> [...] >> >> Some ports want NEON support but FCP-0100 is vague about FreeBSD-specific >> differences between armv6 and armv7. Clang appears to enable NEON for all >> *-gnueabi* targets but I have no clue about GCC. Apparently, Android and >> Debian don't assume NEON on armv7. >> >> related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 >> > > Yes. We are vague about it on purpose. Just like we're vague about MMX, > MMX2, etc on x86 because different processors can/want use different > things. Do you mean similar to how FreeBSD i386 is vague about not supporting real i386, only i486 or later? > The goal, if it doesn't work already, is for NEON to work if used, > but not be required, just like all the other optional features of a CPU. FreeBSD doesn't support detecting NEON at runtime unlike Linux. Do you mean at compile time? If so then the following probably needs to change $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E -https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: FCP-100: armv7 plan
Warner Losh writes: > Greetings, > > This will serve as 'Last Call' for any objections to the plan to create an > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. [...] Some ports want NEON support but FCP-0100 is vague about FreeBSD-specific differences between armv6 and armv7. Clang appears to enable NEON for all *-gnueabi* targets but I have no clue about GCC. Apparently, Android and Debian don't assume NEON on armv7. related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221898 ___ 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"
Re: x11/pixman vs. clang 5 arm assembler handling: "error: unknown directive" and the like
Mark Millard writes: > In an experiment with building some arm ports via poudriere > cross building on amd64 I got the following. It appears that > clang does not handle all the assembler notation and a > different assembler might need to be used for x11/pixman . > (The x11/pixman usage is indirect from having specified > x11/lumina and x11/xscreensaver ). > > --- pixman-arm-simd-asm.lo --- > /bin/sh ../libtool --mode=compile /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H > -I. -I.. -mcpu=cortex-a7 -O2 -pipe -mcpu=cortex-a7 -g > -fno-strict-aliasing -MT pixman-arm-simd-asm.lo -MD -MP -MF > .deps/pixman-arm-simd-asm.Tpo -c -o pixman-arm-simd-asm.lo > pixman-arm-simd-asm.S > libtool: compile: /nxb-bin/usr/bin/cc -DHAVE_CONFIG_H -I. -I.. > -mcpu=cortex-a7 -O2 -pipe -mcpu=cortex-a7 -g -fno-strict-aliasing -MT > pixman-arm-simd-asm.lo -MD -MP -MF .deps/pixman-arm-simd-asm.Tpo -c > pixman-arm-simd-asm.S -fPIC -DPIC -o .libs/pixman-arm-simd-asm.o > :1:1: error: unknown directive > . . . > --- pixman-arm-simd-asm.lo --- > .func fname > ^ Does it still happen after https://svnweb.freebsd.org/changeset/ports/449285 ? ___ 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"
Re: using code coverage with clang
(redirected from -questions@ to -toolchain@) "Jeremy C. Reed" writes: > When I changed from FreeBSD 9.x to 10.0-RELEASE-p1, I went from gcc to > clang. But this causes > /usr/bin/ld: /usr/bin/../lib/libprofile_rt.a: No such file: No such file > or directory > > I don't have that library. Any suggestions on how to get it so I don't > have to maintain later during upgrades. I don't think the clang ports > have it either. With recent Clang the error may error slightly different: $ clang35 foo.c -fprofile-arcs -ftest-coverage /usr/local/bin/ld: cannot find /usr/local/llvm35/bin/../lib/clang/3.5.0/lib/freebsd/libclang_rt.profile-amd64.a: No such file or directory clang: error: linker command failed with exit code 1 (use -v to see invocation) Try installing one of lang/gcc* and adding --rtlib=libgcc to link flags. --rtlib=compiler-rt requires more recent compiler-rt version than the one shipped with FreeBSD base. There's an upstream bug but the patches there have bitrotten to being mostly useless (predate --rtlib support). http://llvm.org/bugs/show_bug.cgi?id=6122 Anyway, freebsd-toolchain@ folk probably know more about the state of Clang coverage/profiling on FreeBSD such as: - devel/compiler-rt being more ancient than version in base on 10.0R - lang/clang* trying to use libgcc_p instead of libs from lang/gcc* - coverage/profiling not agreeing on whether to use libgcc/compiler-rt https://lists.freebsd.org/pipermail/freebsd-toolchain/2013-September/001030.html > > I'd prefer to not maintain all my dependencies (ports) using gcc. > (Currently I cannot use gcc with the clang-built ports as some libraries > appear to be built differently so references aren't seen the same.) > Try either converting USE_GCC=yes ports to USES=compiler:gcc-c++11-lib or adding -nostdinc++ -isystem/usr/include/c++/v1 to CXXFLAGS and creating /usr/lib/libstdc++.so -> libc++.so symlink. > Does anyone have suggestions for doing code coverage with clang? Maybe pmcannotate(8) or dtrace(1) as compiler-agnostic alternatives. > > Or are there binary packages available for 10.0 on amd64 built with gcc? > > (I found a forum discussion about it at > https://forums.freebsd.org/viewtopic.php?f=35&t=47260 and several other > reports about it.) - VFEmail.net - http://www.vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! ___ 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: ports/177224: building www/firefox fails
(toolchain@ may know more about clang-devel behavior)
Tsurutani Naoki writes:
> building with lang/clang successfully finishes, but firefox crashes
> with segmentation fault just after running it.
I've asked (privately) devel/llvm maintainer to incorporate r175057 but
so far he hasn't responded.
http://lists.freebsd.org/pipermail/freebsd-ports/2013-February/081635.html
> building without clang successfully finishes, and no errors.
> I want a knob to choice the compiler.
By setting CC/CXX/CPP you've made the choice. There is no need for a
superfluous option for what every port must allow to do.
It's just the compiler chosen by default doesn't work.
>> ../../dist/bin/libxul.so: undefined reference to `PrepareAndDispatch'
>> ../../dist/bin/libxul.so: undefined reference to `invoke_copy_to_stack'
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>
> building with lang/clang-devel fails (*1).
> (*1) __attribute__((used)) might be ignored with clang-devel (clang 3.3) ?
Perhaps, a compiler bug? The following workaround seems to work for
clang 3.3 but breaks the build for clang 3.2 / gcc 4.6.
--- xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp~
+++ xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp
@@ -82,7 +82,7 @@ __asm__ (
"pushl %edx\n\t"/* push this. esp % 16 == 0 */
"movl 0x14(%ebp), %edx\n\t"
- "call " SYMBOL_UNDERSCORE "invoke_copy_to_stack\n\t"
+ "call " SYMBOL_UNDERSCORE
"_Z20invoke_copy_to_stackjP13nsXPTCVariantPj\n\t"
"movl 0x08(%ebp), %ecx\n\t"/* 'that' */
"movl (%ecx), %edx\n\t"
"movl 0x0c(%ebp), %eax\n\t"/* function index */
--- xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp~
+++ xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp
@@ -118,7 +118,7 @@ asm(".text\n\t"
SYMBOL_UNDERSCORE "SharedStub:\n\t"
"leal 0x08(%esp), %ecx\n\t"
"movl 0x04(%esp), %edx\n\t"
-"jmp " SYMBOL_UNDERSCORE "PrepareAndDispatch\n\t"
+"jmp " SYMBOL_UNDERSCORE
"_Z18PrepareAndDispatchjP14nsXPTCStubBasePj\n\t"
#if !defined(XP_MACOSX)
".size " SYMBOL_UNDERSCORE "SharedStub,.-" SYMBOL_UNDERSCORE
"SharedStub"
#endif
> using [[gnu::used]] instead of above failed:
> % make
> ...
> /usr/local/work/usr/ports/www/firefox/work/mozilla-
> release/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:12:13:
> error:
> '__used__' attribute cannot be applied to types
> static void ATTRIBUTE_USED __attribute__ ((regparm(3)))
> ^
> ../../../../../../../xpcom/reflect/xptcall/src/md/unix/xptc_gcc_x86_unix.h:19:26:
> note:
> expanded from macro 'ATTRIBUTE_USED'
> #define ATTRIBUTE_USED [[gnu::__used__]]
> ^
> 1 error generated.
> %
It may be clang 3.3 is more strict with c++11 attributes. clang 3.2 and
gcc 4.8 would still warn about incorrect placement.
> In file included from
> xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:9:0:
> xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp: At global
> scope:
> xpcom/reflect/xptcall/src/md/unix/xptc_gcc_x86_unix.h:19:24: warning:
> attribute ignored [-Wattributes]
> #define ATTRIBUTE_USED [[gnu::used]]
> ^
> xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:12:13: note: in
> expansion of macro 'ATTRIBUTE_USED'
> static void ATTRIBUTE_USED __attribute__ ((regparm(3)))
> ^
> xpcom/reflect/xptcall/src/md/unix/xptc_gcc_x86_unix.h:19:24: note: an
> attribute that appertains to a type-specifier is ignored
> #define ATTRIBUTE_USED [[gnu::used]]
> ^
> xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:12:13: note: in
> expansion of macro 'ATTRIBUTE_USED'
> static void ATTRIBUTE_USED __attribute__ ((regparm(3)))
> ^
And if you put [[gnu::used]] between invoke_copy_to_stack and ()
the mangling issue happens again.
___
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: ports/170256: audio/mpg123: SIGNAL 10 (SIGBUS) error
The bug probably happens with every .mp3 file.
Program received signal SIGBUS, Bus error.
mpg123_strlen () at dct64_x86_64.S:117
117 movaps (%rcx), %xmm0
(gdb) bt
#0 mpg123_strlen () at dct64_x86_64.S:117
#1 0x00080085e416 in INT123_synth_1to1_stereo_x86_64
(bandPtr_l=0x801c5a700,
bandPtr_r=0x801c5b000, fr=0x801c14000) at synth.c:430
#2 0x00080086b55f in INT123_do_layer3 (fr=0x801c14000) at layer3.c:2028
#3 0x000800858c21 in decode_the_frame (fr=0x801c14000) at libmpg123.c:685
#4 0x0008008595b7 in mpg123_decode_frame (mh=0x801c14000, num=0x624528,
audio=0x7fffda40, bytes=0x7fffda30) at libmpg123.c:824
#5 0x0040e445 in play_frame () at mpg123.c:661
#6 0x0040ff11 in main (sys_argc=2, sys_argv=0x7fffdd28)
at mpg123.c:1140
And this is caused by a broken .align check in configure.ac:
$ echo '.align 3' | clang -c -o /dev/null -x assembler -
$ echo '.align 3' | gcc47 -c -o /dev/null -x assembler -
{standard input}: Assembler messages:
{standard input}:1: Error: alignment not a power of 2
Exit 1
$ echo '.align 3' | as -o /dev/null
{standard input}: Assembler messages:
{standard input}:1: Error: alignment not a power of 2
Exit 1
No clue whose bug is this but here's a workaround.
--- configure.ac~
+++ configure.ac
@@ -838,21 +838,21 @@
dnl ## Assembler, compiler properties
# based on posting from John Dalgliesh on ffmpeg (LGPL)
mailing list
# find if .align arg is power-of-two or not
asmalign_exp="unknown"
if test x"$asmalign_exp" = xunknown; then
AC_MSG_CHECKING([if .align takes 2-exponent])
asmalign_exp="no"
echo '.align 3' > conftest.s
- if $CCAS -c -o conftest.o conftest.s 1>/dev/null 2>&1; then
+ if $AS -c -o conftest.o conftest.s 1>/dev/null 2>&1; then
asmalign_exp="yes"
AC_MSG_RESULT([yes])
else
AC_MSG_RESULT([no])
fi
rm -f conftest.o conftest.s
fi
if test x"$asmalign_exp" = xyes; then
AC_DEFINE(ASMALIGN_EXP, 1, [ Define if .align takes 3 for alignment of
2^3=8 bytes instead of 8. ])
fi
___
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: Clang as default compiler November 4th
Doug Barton writes:
> On 09/11/2012 02:52 AM, Erik Cederstrand wrote:
>> So can we do a sweep on the ports tree and mark the 2232 ports with
>> USE_GCC=4.2 until they can actually build with clang?
>
> Unfortunately it isn't that simple. We already have a statistically
> significant number of ports that don't even compile with gcc 4.2.1. How
> many compilers do we expect the users to install? :)
>
> What we need to do is what I and others have been asking to do for
> years. We need to designate a modern version of gcc (no less than 4.6)
> as the official default ports compiler, and rework whatever is needed to
> support this. Fortunately, that goal is much more easily achieved than
> fixing ports to build and run with clang. (It's harder than it sounds
> because there are certain key libs that define some paths depending on
> what compiler they were built with, but still easier than dealing with
> clang in the short term.)
To that effect ports also need to respect CC/CXX. There were a few -exp
runs without /usr/bin/{cc,gcc,etc} to find out non-conforming ones as
part of ports/159117. However, the issue was quickly shoved under the
carpet in order to focus on the more important, clang as default.
# last try, assumes_gcc are ports ignoring CC/CXX, many are fixed
http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp.20110723205754/index-reason.html
>
> Once that is done, the compiler in the base is an afterthought, and we
> can do away with gcc in the base altogether much more easily. Users who
> want to help support building ports with clang can continue to do so.
>
> Doug
--
Ignoring for the moment clang -exp runs are *still* done with clang 3.0
while we're discussing here clang 3.2 becoming default.
___
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"
