Re: RELENG_8 does not build with CPUTYPE=core2
I had discovered this method of working around the fatal error, but the question remains: Should buildworld ever use the base compiler once the bootstrap compiler is built? Much of buildworld had already completed with "-march=core2" being fed to the bootstrap compiler by the time this error occurs. -Scott Oliver Pinter wrote: in two step you can elliminate the warning message: 1) compile and install world and kernel with commented CPUTYPE in make.conf 2) uncomment the CPUTYPE line, and recompile world and kernel the problem is, the build system based on newer (4.2.2) gcc, and when you set CPUTYPE=core2 than substitute -march=core2 in gcc parameter list, but older base system cc (4.2.1) do not knows this option or value. On 5/14/11, Dominic Fandrey wrote: On 14/05/2011 02:38, Scott Allendorf wrote: Dominic Fandrey wrote: env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 -pipe -march=core2 -DHAVE_CONFIG_H -I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c make-roken.c /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: error: bad value (core2) for -march= switch /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: error: bad value (core2) for -mtune= switch make-roken.c:1: error: bad value (core2) for -march= switch make-roken.c:1: error: bad value (core2) for -mtune= switch distcc[44991] ERROR: compile make-roken.c on localhost failed *** Error code 1 ... I saw this too when updating systems across the compiler update. As near as I can tell, some part of the build is not using the new "core2"-aware compiler built as part of the toolchain and is using the older, installed version instead. Commenting out the CPUTYPE definition allowed my buildworlds to complete successfully. ... Thanks for the workaround! It still worries me, that there's a bug in the bootstrapping. You never know what kind of trouble comes from that kind of thing. I hope this is going to be fixed. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Scott C. Allendorf Email: scott-allend...@uiowa.edu Senior Systems Administrator Office: 216A Van Allen Hall Department of Physics and AstronomyVoice: (319) 335-0003 The University of Iowa FAX: (319) 335-1753 Iowa City, Iowa 52242-1479ICBM: 41 39 43.6 N 91 31 55.1 W smime.p7s Description: S/MIME Cryptographic Signature
Re: RELENG_8 does not build with CPUTYPE=core2
Dominic Fandrey wrote: env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -O2 -pipe -march=core2 -DHAVE_CONFIG_H -I/usr/src/kerberos5/tools/make-roken/../../include -std=gnu99 -c make-roken.c /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: error: bad value (core2) for -march= switch /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c:1: error: bad value (core2) for -mtune= switch make-roken.c:1: error: bad value (core2) for -march= switch make-roken.c:1: error: bad value (core2) for -mtune= switch distcc[44991] ERROR: compile make-roken.c on localhost failed *** Error code 1 1 error *** Error code 2 distcc[44988] ERROR: compile /usr/src/kerberos5/tools/make-print-version/../../../crypto/heimdal/lib/vers/make-print-version.c on localhost failed *** Error code 1 1 error *** Error code 2 2 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 # make -VCPUTYPE nocona # make -VCFLAGS -O2 -pipe -march=nocona CPUTYPE is set with CPUTYPE?=core2. I saw this too when updating systems across the compiler update. As near as I can tell, some part of the build is not using the new "core2"-aware compiler built as part of the toolchain and is using the older, installed version instead. Commenting out the CPUTYPE definition allowed my buildworlds to complete successfully. After the resulting system was installed I was then able to restore CPUTYPE to "core2" and 'make buildworld' would succeed (presumably because the base system compiler now understands "-march=core2"). Hope this help... -Scott -- Scott C. Allendorf Email: scott-allend...@uiowa.edu Senior Systems Administrator Office: 216A Van Allen Hall Department of Physics and AstronomyVoice: (319) 335-0003 The University of Iowa FAX: (319) 335-1753 Iowa City, Iowa 52242-1479ICBM: 41 39 43.6 N 91 31 55.1 W smime.p7s Description: S/MIME Cryptographic Signature
Re: Floppy drive not detected after 8.0-RELEASE->8.1-PRERELEASE
Jung-uk Kim wrote: On Friday 28 May 2010 03:35 pm, Scott Allendorf wrote: Andriy Gapon wrote: on 28/05/2010 19:32 Scott Allendorf said the following: I recently upgraded to 8.1-PRERELEASE (amd64) on a Dell Optiplex 960 running 8.0-RELEASE. After the upgrade, my floppy drive was no longer detected. After a binary search, the following commit appears to be responsible: http://svn.freebsd.org/viewvc/base?view=revision&revision=203544 Can you check if reverting of MFC of the following helps (it's a part of that big ACPI MFC)? r200554 | jkim | 2009-12-15 00:28:32 +0200 (Tue, 15 Dec 2009) | 3 lines Remove _FDE quirk handling as these quirks are automatically repaired by ACPICA layer since ACPICA 20091214. Thank you for your quick reply to my message. Reverting this change (src/sys/dev/fdc/fdc_acpi.c from 1.13.2.2 to 1.13.2.1) appears to have fixed the issue. The floppy drive is now detected and it is functional. There do not appear to be any side effects. Please try the attached patch. Sorry, it was stupid. :-( Jung-uk Kim Applying the patch to r200554 of fdc_acpi.c (1.13.2.2) appears to fix the issue. Once again, the floppy drive is detected and it is functional. There do not appear to be any side effects. Thank you, Scott -- Scott C. Allendorf Email: scott-allend...@uiowa.edu UNIX Systems Administrator Office: 216A Van Allen Hall Department of Physics and AstronomyVoice: (319) 335-0003 The University of Iowa FAX: (319) 335-1753 Iowa City, Iowa 52242-1479ICBM: 41 39 43.6 N 91 31 55.1 W smime.p7s Description: S/MIME Cryptographic Signature
Re: Floppy drive not detected after 8.0-RELEASE->8.1-PRERELEASE
Andriy Gapon wrote: on 28/05/2010 19:32 Scott Allendorf said the following: I recently upgraded to 8.1-PRERELEASE (amd64) on a Dell Optiplex 960 running 8.0-RELEASE. After the upgrade, my floppy drive was no longer detected. After a binary search, the following commit appears to be responsible: http://svn.freebsd.org/viewvc/base?view=revision&revision=203544 Can you check if reverting of MFC of the following helps (it's a part of that big ACPI MFC)? r200554 | jkim | 2009-12-15 00:28:32 +0200 (Tue, 15 Dec 2009) | 3 lines Remove _FDE quirk handling as these quirks are automatically repaired by ACPICA layer since ACPICA 20091214. Thank you for your quick reply to my message. Reverting this change (src/sys/dev/fdc/fdc_acpi.c from 1.13.2.2 to 1.13.2.1) appears to have fixed the issue. The floppy drive is now detected and it is functional. There do not appear to be any side effects. Cheers, Scott -- Scott C. Allendorf Email: scott-allend...@uiowa.edu UNIX Systems Administrator Office: 210B Van Allen Hall Department of Physics and AstronomyVoice: (319) 335-0003 The University of Iowa FAX: (319) 335-1753 Iowa City, Iowa 52242-1479ICBM: 41 39 43.6 N 91 31 55.1 W smime.p7s Description: S/MIME Cryptographic Signature
Floppy drive not detected after 8.0-RELEASE->8.1-PRERELEASE
I recently upgraded to 8.1-PRERELEASE (amd64) on a Dell Optiplex 960 running 8.0-RELEASE. After the upgrade, my floppy drive was no longer detected. After a binary search, the following commit appears to be responsible: http://svn.freebsd.org/viewvc/base?view=revision&revision=203544 uname -a output: === FreeBSD scatest2.physics.uiowa.edu 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu May 27 14:09:09 CDT 2010 s...@scatest2.physics.uiowa.edu:/usr/obj/usr/src/sys/GELFAND amd64 === The floppy-related lines from a verbose boot before the commit: === fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 fdc: fdc0 already exists; skipping it === The floppy-related lines from a verbose boot after the commit: === fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [FILTER] fdc: fdc0 already exists; skipping it fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout === Has anyone else seen this or am I the only person that still needs floppy drives to work? This is a test system, so I am able to test potential fixes at will. Thanks, Scott -- Scott C. Allendorf Email: scott-allend...@uiowa.edu UNIX Systems Administrator Office: 210B Van Allen Hall Department of Physics and AstronomyVoice: (319) 335-0003 The University of Iowa FAX: (319) 335-1753 Iowa City, Iowa 52242-1479ICBM: 41 39 43.6 N 91 31 55.1 W smime.p7s Description: S/MIME Cryptographic Signature
3.4S->4.0S upgrade: make buildworld failing
I am attempting to upgrade from 3.4-STABLE (cvsupped/built late last week) to 4.0-STABLE cvsupped this morning into a clean /usr/src. The supfile was /usr/src/share/examples/cvsup/stable-supfile with cvs-crypto uncommented and RELENG_3 changed to RELENG_4. Whenever MAKE_KERBEROS4 is uncommented in /etc/make.conf, "make buildworld" fails with the error shown below. Adding "RSAREF= YES" to /etc/make.conf does not change anything. Commenting out the MAKE_KERBEROS4 definition allows the build to complete. Is anyone else seeing this? Is it pilot error or have I stumbled onto a problem or an omission in the instructions in /usr/src/UPDATING? Cheers, Scott Script started on Tue Mar 21 13:03:32 2000 host# grep -v ^\# /etc/make.conf CFLAGS= -O -pipe COPTFLAGS= -O -pipe COMPAT1X= yes COMPAT20= yes COMPAT21= yes COMPAT22= yes HAVE_MOTIF= yes USA_RESIDENT= YES MAKE_KERBEROS4= yes SUP_UPDATE= yes SUP=/usr/local/bin/cvsup SUPFLAGS= -g -L 2 SUPFILE=/usr/local/etc/cvsup/stable-supfile SUPFILE2= /usr/local/etc/cvsup/ports-supfile TOP_TABLE_SIZE= 101 host# cd /usr/src host# ls /usr/obj host# make buildworld -- >>> Rebuilding the temporary build tree -- ... All was well until ... ===> libkadm ln -sf /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/include/protos.H protos.h rm -f .depend mkdep -f .depend -a -I/usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/include -I/usr/obj/usr/src/kerberosIV/lib/libkadm/../../include -I/usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/krb -I/usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kdb -I/usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm -I/usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/roken -I/usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb -I/usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm -I/usr/obj/usr/src/kerberosIV/lib/libkadm -I/usr/src/kerberosIV/lib/libkadm/../../include -DHAVE_CONFIG_H -I/usr/obj/usr/src/kerberosIV/lib/libkadm/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -I/usr/obj/usr/src/i386/usr/include /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_cli_wrap.c /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_stream.c /usr/src/kerberosIV/lib/libkadm/..! /../../crypto/kerberosIV/lib/kadm/kadm_supp.c /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.c /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/check_password.c In file included from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_locl.h:75, from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_cli_wrap.c:30: /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:17: invalid macro name In file included from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_locl.h:78, from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_cli_wrap.c:30: /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:13: warning: `ERROR_TABLE_BASE_' redefined /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:13: warning: this is the location of the previous definition /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:17: invalid macro name In file included from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_locl.h:75, from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_stream.c:38: /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:17: invalid macro name In file included from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_locl.h:78, from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_stream.c:38: /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:13: warning: `ERROR_TABLE_BASE_' redefined /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:13: warning: this is the location of the previous definition /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkadm/kadm_err.h:17: invalid macro name In file included from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_locl.h:75, from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_supp.c:36: /usr/obj/usr/src/kerberosIV/lib/libkadm/../../lib/libkrb/krb_err.h:17: invalid macro name In file included from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_locl.h:78, from /usr/src/kerberosIV/lib/libkadm/../../../crypto/kerberosIV/lib/kadm/kadm_supp.c:36: /usr/obj/usr/src/kerberosIV/lib/libkadm/.
