Date: Thu, 29 Jul 2004 02:32:59 +0000 From: Alexander Kabaev <kan@FreeBSD.ORG> To: current@FreeBSD.ORG Cc: Andrzej Tobo??a <ato@iem.pw.edu.pl> Subject: Compiling FreeBSD with non-standard flags. Message-ID: <20040729023259.GA47439@freefall.freebsd.org> In-Reply-To: <20040728205444.GA51189@volt.iem.pw.edu.pl> References: <200407280312.i6S3C39q070966@repoman.freebsd.org> <20040728205444.GA51189@volt.iem.pw.edu.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello all, > % make buildworld > ..... > ===> libexec/atrun > cc -O2 -fomit-frame-pointer -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 -c /usr/src/libexec/atrun/atrun.c > cc -O2 -fomit-frame-pointer -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 -c /usr/src/libexec/atrun/gloadavg.c > cc -O2 -fomit-frame-pointer -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 -o atrun atrun.o gloadavg.o > /usr/obj/usr/src/i386/usr/lib/libc.so: undefined reference to `pthread_mutex_destroy_int' > /usr/obj/usr/src/i386/usr/lib/libc.so: undefined reference to `pthread_cond_destroy_exp' > .......... > There were a number of reports of buildworld breakage due to people using non-default flags like -Os, -O2 and even -fomit-frame-pointer. While desire to squeeze the very last drop of performance out of their systems is understandable goal, you should understand, that you are on your own while you are doing that, especially right after a major GCC version upgrade. I will try to fix this particular breakage when other, more pressing issues have been addressed. -- Alexander Kabaev
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040729023259.GA47439>