Buildworld on 9.1-RC2 fails on top?

O

Orum

Haven't found anyone else with this bug, so I thought it might be a configuration issue on my end. Current system is
Code: 
FreeBSD 9.1-PRERELEASE #0: Thu Sep 27 13:26:42 UTC 2012 amd64
and I'm trying to upgrade to
Code: 
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/releng/9.1
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 241510
Node Kind: directory
Schedule: normal
Last Changed Author: gabor
Last Changed Rev: 241445
Last Changed Date: 2012-10-11 15:49:42 +0000 (Thu, 11 Oct 2012)
/etc/make.conf is
Code: 
WITHOUT_X11=yes
CFLAGS=-O -pipe

KERNCONF=PYRITE

# added by use.perl 2012-09-29 07:14:23
PERL_VERSION=5.12.4
/etc/src.conf looks like this
Code: 
# src.conf
CC=clang
CXX=clang++
CPP=clang-cpp
NO_FSCHG=

WITHOUT_ATM="yes"
WITHOUT_BIND="yes"
WITHOUT_BLUETOOTH="yes"
WITHOUT_FLOPPY="yes"
WITHOUT_FREEBSD_UPDATE="yes"
WITHOUT_GAMES="yes"
WITHOUT_HTML="yes"
WITHOUT_IPFILTER="yes"
WITHOUT_IPFW="yes"
WITHOUT_IPX="yes"
WITHOUT_KERBEROS="yes"
WITHOUT_KERNEL_SYMBOLS="yes"
WITHOUT_LIB32="yes"
WITHOUT_LPR="yes"
WITHOUT_NDIS="yes"
WITHOUT_NTP="yes"
WITHOUT_PAM_SUPPORT="yes"
WITHOUT_PORTSNAP="yes"
WITHOUT_ROUTED="yes"
WITHOUT_SENDMAIL="yes"
Note that the system that is currently running was built by gcc, but otherwise with the same src.conf file that you see there. The current buildworld fails using either gcc or clang, and it fails when compiling top with (when using clang)
Code: 
clang -O -pipe  -DHAVE_GETOPT -DHAVE_STRERROR -DORDER -I/usr/src/usr.bin/top -I/
usr/src/usr.bin/top/../../contrib/top -I. -std=gnu99 -Qunused-arguments -fstack-
protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautologic
al-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno
-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -c /usr/src/usr.bin/to
p/machine.c
/usr/src/usr.bin/top/machine.c:266:2: error: use of undeclared identifier
      'y_arc'
        y_arc = 4;
        ^
/usr/src/usr.bin/top/machine.c:276:3: error: use of undeclared identifier
      'y_arc'
                y_arc += ncpus - 1;
                ^
/usr/src/usr.bin/top/machine.c:348:12: error: no member named 'arc_names' in
      'struct statics'
                statics->arc_names = arcnames;
                ~~~~~~~  ^
/usr/src/usr.bin/top/machine.c:350:12: error: no member named 'arc_names' in
      'struct statics'
                statics->arc_names = NULL;
                ~~~~~~~  ^
/usr/src/usr.bin/top/machine.c:529:7: error: no member named 'arc' in
      'struct system_info'
                si->arc = arc_stats;
                ~~  ^
/usr/src/usr.bin/top/machine.c:904:19: warning: format specifies type 'int' but
      the argument has type 'unsigned long' [-Wformat]
                                warn("malloc(%d)", argbuflen + 1);
                                             ~^    ~~~~~~~~~~~~~
                                             %ld
/usr/src/usr.bin/top/machine.c:958:42: warning: field width should have type
      'int', but argument has type 'unsigned long' [-Wformat]
                snprintf(jid_buf, sizeof(jid_buf), " %*d",
                                                     ~~^
/usr/src/usr.bin/top/machine.c:1003:41: warning: field width should have type
      'int', but argument has type 'unsigned long' [-Wformat]
                snprintf(thr_buf, sizeof(thr_buf), "%*d ",
                                                    ~~^
3 warnings and 5 errors generated.
*** [machine.o] Error code 1

Stop in /usr/src/usr.bin/top.
*** [all] Error code 1

Stop in /usr/src/usr.bin.
*** [usr.bin.all__D] Error code 1

Stop in /usr/src.
*** [everything] Error code 1

Stop in /usr/src.
*** [buildworld] Error code 1

Stop in /usr/src.
Which looks like it's related to some of the zfs information provided by top. make clean was run before all attempted builds, and even with an unchanged src.conf from 9.1-PRERELEASE, things fail. The only other big change since the last build was synchronizing the source via SVN instead of CVS. Any ideas?
 
Orum said:
/etc/make.conf is
Code: 
CFLAGS=-O -pipe
Click to expand...

Don't do that. More specifically: don't set CFLAGS. At all. They will not improve your operating system build, and more often will cause problems. They will also limit ports that can use improved CFLAGS and have them set as part of the port.

make clean was run before all attempted builds
Click to expand...

With buildworld or buildkernel, it is quicker to just delete the contents of /usr/obj/. 0.06 seconds versus 13.28 seconds on my system.
 
wblock@ said:
Don't do that. More specifically: don't set CFLAGS. At all. They will not improve your operating system build, and more often will cause problems. They will also limit ports that can use improved CFLAGS and have them set as part of the port.
Click to expand...
If this is the case, then the documentation needs to be updated. It says: "A typical user will probably want to copy the CFLAGS and NO_PROFILE lines found in /usr/share/examples/etc/make.conf to /etc/make.conf and uncomment them." Looking at that file, it has even more CFLAGS than I set, as its line is
Code: 
CFLAGS= -O2 -fno-strict-aliasing -pipe

More importantly, even removing CFLAGS, the build fails in exactly the same spot, with exactly the same error.

wblock@ said:
With buildworld or buildkernel, it is quicker to just delete the contents of /usr/obj/. 0.06 seconds versus 13.28 seconds on my system.
Click to expand...

Yeah, I was unsure if removing /usr/obj/* did everything make clean did, so I decided to stay on the safe side and just run make clean. Typically I remove /usr/obj/* after a successful installation and don't bother with make clean.
 
Orum said:
If this is the case, then the documentation needs to be updated. It says: "A typical user will probably want to copy the CFLAGS and NO_PROFILE lines found in /usr/share/examples/etc/make.conf to /etc/make.conf and uncomment them." Looking at that file, it has even more CFLAGS than I set, as its line is
Code: 
CFLAGS= -O2 -fno-strict-aliasing -pipe
Click to expand...

Which document is that in?
 
That part of the handbook needs rewriting. Many of the Makefiles in the system sources have hand-crafted CFLAGS to avoid compiler bugs etc. and if you forcibly override CFLAGS you can't be sure that the compiler produces correct code.
 
Fair enough, but it doesn't solve the issue. I'd like to revert to 9.1-RC1 sources, but I can't find any mapping of SVN revision numbers to RC tags.
 
Those erroneous CFLAGS recommendations have been removed from the Handbook.

Getting releng/9.1 from svn should get you the latest version of what will become 9.1-RELEASE.
 
Right, but as I said, 9.1-RC2 (or whatever is the latest of 9.1 right now, which appears to be r241445) doesn't compile, regardless of CFLAGS. I was on 9.1-PRERELEASE shortly after RC1 came out, and would like to go back to that. Unfortunately I don't know what the SVN revision number would have been, as that was a CVS sync. I'd just like to know what previous SVN revision was RC1 or even just close to it, so I can go back to using the old sources that did compile.
 
Nope, hardware. Only other oddities other than what I mentioned in the first post is this machine is ZFS root, but I've successfully recompiled before on this machine. Without the CFLAGS the only changes I've made are what's in src.conf, which worked on 9.1-PRERELEASE (back when synced via CVS shortly after 9.1-RC1 became available, likely just before Thu Sep 27 13:26:42 UTC 2012).

Edit: Actually, that date gives me an idea. Can I just look up the last SVN commit before that time, and sync to that?
 
See svn help co. Not only can it take a revision number, it can take a date, which will give the first revision as of that date. Um... not that I have tested either...
 
If it's 9-STABLE I'd try to get the sources again. I've had it happen a couple of times when I appeared to have updated my sources in the middle of a large commit. That gave me all sorts of weird errors.

Simply updating the source again usually fixes those issues.
 
SirDice said:
If it's 9-STABLE I'd try to get the sources again. I've had it happen a couple of times when I appeared to have updated my sources in the middle of a large commit. That gave me all sorts of weird errors.
Click to expand...

I've been running svn up /usr/src several times, but the "Last Changed Rev" always stayed at r241445. Only the repository revision number (which I assume is for the whole repo and not just the branch) would increment.

Anyway, more weirdness. I checked out the sources as of Sep 27, 2012, and tried a buildworld again. It failed, again with the same error as the current revision. Tried "svn up" to go back to current, and I get these errors:
Code: 
Updating '/usr/src':
Skipped '/usr/src/release' -- Node remains in conflict
Skipped '/usr/src/contrib' -- Node remains in conflict
Skipped '/usr/src/sys' -- Node remains in conflict
At revision 241602.
Summary of conflicts:
  Skipped paths: 3
Which I don't understand why I'm getting, even after searching around a bit, as the only thing I've ever changed in the working copy was to add in my kernel config. So, I rm'd /usr/src/.svn and checked out releng 9.1 again, and I was back to "Last Changed Rev: 241445". Then I had an idea--If these truly are the correct sources and Subversion synced correctly, I shouldn't have any changes if I switch back to CVS, right? So I csuped with this supfile:
Code: 
*default host=cvsup6.us.freebsd.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=RELENG_9_1
*default delete use-rel-suffix
*default compress

src-all
...and loads of changes! So many I couldn't even see if /usr/src/usr.bin/top/machine.c was updated, even with tmux's lengthy scrollback buffer. The only justification for so many changes for that would be if the CVS mirror "lags" behind the SVN repo, which seems unlikely unless the devs only export to CVS infrequently; or there are some unavoidable changes when going from a SVN repo to a CVS repo. Unfortunately I don't know what the equivalent SVN revision would be of the CVS source I fetched. Is there a way to find out?

More importantly, the world build succeeds now. So, two more questions:
  • Why do I get different source files when I sync via CVS vs SVN?
  • Why does the code retrieved via SVN fail to compile?

Edit: Have confirmed that the sources from CVS are RC2
Code: 
FreeBSD pyrite 9.1-RC2 FreeBSD 9.1-RC2 #0: Tue Oct 16 05:13:29 UTC 2012     root@pyrite:/usr/obj/usr/src/sys/PYRITE  amd64

Edit2: It appears that I'm having the same conflicts with the ports tree as well. Almost, if not every subdirectory and file under /usr/ports fails to sync via svn with the mysterious error: "Node remains in conflict".
 
Make certain there isn't a cron(8) job also updating sources or ports, or possibly part of an update script run by hand. Removing all of a tree, either /usr/src or /usr/ports, before the initial checkout is a good idea. Don't do separate checkouts of subtrees, it is not the same as a single checkout of the main tree.

Finding which files are conflicting may help identify the cause:
% svn stat /usr/src
 
Nothing in cron, so I rm'ed everything in /usr/src, including .svn, and started from scratch. Everything (i.e. builds and svn up) seems to be working now, for both src and ports.

Thanks, I owe you guys a beer. :beergrin
 
You must log in or register to reply here.
Back
Top