# Buildworld on 9.1-RC2 fails on top?



## Orum (Oct 13, 2012)

Haven't found anyone else with this bug, so I thought it might be a configuration issue on my end.  Current system is

```
FreeBSD 9.1-PRERELEASE #0: Thu Sep 27 13:26:42 UTC 2012 amd64
```
and I'm trying to upgrade to

```
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

```
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

```
# 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)

```
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?


----------



## wblock@ (Oct 13, 2012)

Orum said:
			
		

> /etc/make.conf is
> 
> ```
> CFLAGS=-O -pipe
> ```



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



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.


----------



## Orum (Oct 14, 2012)

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.


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
	
	



```
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.



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.


----------



## wblock@ (Oct 14, 2012)

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
> 
> 
> 
> ...



Which document is that in?


----------



## Orum (Oct 14, 2012)

The handbook: Rebuilding "world"


----------



## kpa (Oct 14, 2012)

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.


----------



## Orum (Oct 15, 2012)

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.


----------



## wblock@ (Oct 15, 2012)

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.


----------



## Orum (Oct 15, 2012)

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.


----------



## wblock@ (Oct 15, 2012)

9-stable as of a couple of hours ago compiles for me.  Is  yours running in a VM?


----------



## Orum (Oct 15, 2012)

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?


----------



## wblock@ (Oct 15, 2012)

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...


----------



## SirDice (Oct 15, 2012)

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.


----------



## Orum (Oct 16, 2012)

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.



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:

```
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:

```
*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

```
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".


----------



## wblock@ (Oct 16, 2012)

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`


----------



## Orum (Oct 16, 2012)

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


----------

