06.09.2011 01:11, Olivier Smedts wrote:
===>    libexec/atrun (all)
clang -O2 -pipe -march=native -DATJOB_DIR=\"/var/at/jobs/\"
-DLFILE=\"/var/at/jobs/.lockfile\"  -DLOADAVG_MX=1.5
-DATSPOOL_DIR=\"/var/at/spool\"  -DVERSION=\"2.9\" -DDAEMON_UID=1
-DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
-DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign
-c /usr/src/libexec/atrun/atrun.c

Try removing "-march=native" from your CFLAGS.

I have the exact same problem since months on my Core i7 CPU when
using "-march=native" or "-march=corei7". No problems for me with
"-march=core2" though.

It so nice you have noted that. I'll be much happier if you also spare some
time reading my previous emails.

Or you could search this mailing list for the exact same problem
reported some time ago.

Well... I know that clang with -march=native can produce flawed binaries but it's quite common for them to SEGFAULT and SIGILL so I made at least a clean build to check that this is not the problem.

As I noted before this command fails only if run as a part of 'make
buildworld'. If I cd to that directory and run the same command from there
it completes successfully yielding working binary. If the error would be
related to -fPIC, ccache or -march it'll end up with other bunch of error
messages and result would be irrelevant of invocation and environment.

If you cd to that directory, you'll use the system clang, let's call
it the "good" clang.

If you buildworld with -march=native or -march=corei7, you'll first
compile a bootstrap clang with -march=native or -march=corei7 (the
"bad" one) and that one will fail building libexec/atrun. Chicken and
egg problem.

If you try building and installing clang with -march=native or
-march=corei7, you'll have the same error if you then cd to that
directory and make.

As I suspect some incorrect buildworld behavior I have no other choice as
running another clean build and presenting new logs. Here you go:

I really mean a clean build here. /usr/obj was wiped and I started from scratch. And it gives me the same error. This is not the problem with -march.

clang -O2 -pipe  -DATJOB_DIR=\"/var/at/jobs/\"
-DLFILE=\"/var/at/jobs/.lockfile\"  -DLOADAVG_MX=1.5
-DATSPOOL_DIR=\"/var/at/spool\"  -DVERSION=\"2.9\" -DDAEMON_UID=1
-DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
-DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at
-I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
-Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialize
d -Wno-pointer-sign  -o atrun atrun.o gloadavg.o -lpam -lutil
clang: warning: argument unused during compilation: '-std=gnu99'

Anyway you are right. Using /usr/obj/usr/src/tmp/usr/bin/clang gives me the same error while installed clang works. So this is really problem with clang.

--
Sphinx of black quartz judge my vow.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to