Re: -current broken when src is on NFS
> Given that we have (or at least had at one time) some of those magical > "..." paths that cause bmake to search up the hierarchy for its .mk > files, I wonder if an odd relationship between src and obj dir confuses > it, or if it somehow wanders into a wrong src tree while searching? Based on Daniel's latest mail, the issue would appear to be the way he was setting MAKEOBJDIRPREFIX. As for .../ src.sys.env.mk resolves that to absolute path since otherwise things like kernel builds wouldn't work - make run from within obj tree. ___ 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"
Re: -current broken when src is on NFS
On Sun, Jul 19, 2015 at 10:31:36AM -0600, Ian Lepore wrote: > > I've been following this saga (on irc and here) as much as I have time > for, and I can't escape the feeling that it is the directory structure > at fault somehow, but I can't quite put my finger on it. > > I never (ever) build from /usr/src or use /usr/obj as an object dir > (they're both empty dirs on all my machines). But one thing that is > always true for me is that the source dir and its related object dir are > siblings in the same parent dir. That is, it's always > >/any/path/here > obj/ > src/ Well, as counterpoint The systems where I do FreeBSD builds are usually set up (and have been since about 1999) so that: * The sources reside in /usr/src. * The file system layput is such that: + /usr is on a different file system from /, but these reside in partitions 4 and 1 (respectively) of the same slice. + /var is a file system that resides on a partition on slice 4. + swap is on slice 4, partition 2. + /tmp is a swap-backed tmpfs. (Well, the implementation of that has changed over the years -- used to be mfs.) + My home directory resides in a file system on a partition in slice 4 mounted on /common -- along with quite a few other things that do not need to physically be on the same slice that I booted from. + /usr/ports is a symlink to an SVN working copy (was a CVS working directory once upon a time) that's in the same file system as my home directory. + Historically, /usr/local was also a symlink to a hierarchy in that same file system. (I only built ports under stable, but used them under both stable and head.) + /usr/obj is also a symlink to a hierarchy in that same file system (/common) -- I had one for each slice (/common/S{1,2,3,4}). * Each of slices 1, 2, and 3 has a / and a /usr file system (as described above); slice 4 has those, as well as swap, /var, /common, and (often) a few others (e.g., /repo or /bkp). * If I'm merely booting to single-user mode, each of the 4 slices is independent of the others, and I can boot any of them. As soon as I start setting up swap, I become dependent on slice 4 (if I wasn't already booted from it). It is not at all uncommon for me to "clone" one slice to another using a 'dump | restore' pipeline; by having the actual contents of /usr/obj in a separate file system, it is easy to make copying that optional -- and if my intent is to move it (vs. copy), renaming a directory is pretty fast and cheap. > Given that we have (or at least had at one time) some of those magical > "..." paths that cause bmake to search up the hierarchy for its .mk > files, I wonder if an odd relationship between src and obj dir confuses > it, or if it somehow wanders into a wrong src tree while searching? > ... Well, I suspect that if that were an issue, I'd likely have encountered it (while muttering further deprecation against realpath all the while). :-} Peace, david -- David H. Wolfskill da...@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpsYPDXAjyiE.pgp Description: PGP signature
Re: -current broken when src is on NFS
On Sat, 2015-07-18 at 10:26 -0700, Simon J. Gerraty wrote: > O'Connor, Daniel wrote: > > However, Crochet _does_ build on the NFS client _and_ when the source > > tree isn't in /usr/src which makes this issue very strange :-/ > > I've seen similar errors in rescue... (no NFS) though I cannot > quite recall the cause other than it seems very sensitive > to MAKEOBJDIRPREFIX value. I've been following this saga (on irc and here) as much as I have time for, and I can't escape the feeling that it is the directory structure at fault somehow, but I can't quite put my finger on it. I never (ever) build from /usr/src or use /usr/obj as an object dir (they're both empty dirs on all my machines). But one thing that is always true for me is that the source dir and its related object dir are siblings in the same parent dir. That is, it's always /any/path/here obj/ src/ Given that we have (or at least had at one time) some of those magical "..." paths that cause bmake to search up the hierarchy for its .mk files, I wonder if an odd relationship between src and obj dir confuses it, or if it somehow wanders into a wrong src tree while searching? -- Ian ___ 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"
Re: -current broken when src is on NFS
O'Connor, Daniel wrote: > However, Crochet _does_ build on the NFS client _and_ when the source > tree isn't in /usr/src which makes this issue very strange :-/ I've seen similar errors in rescue... (no NFS) though I cannot quite recall the cause other than it seems very sensitive to MAKEOBJDIRPREFIX value. ___ 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"
Re: -current broken when src is on NFS
> On 18 Jul 2015, at 13:59, Tim Kientzle wrote: > Crochet defaults MAKEOBJDIRPREFIX to ${WORKDIR}/obj if you have not already > set it to something else. (This avoids cross-polluting the builds if you do > regular manual cross-builds on the same machine.) > > If you’re having issues with /usr/obj being on NFS, that could be a factor. I removed NFS from the equation by building on the machine holding the source and it still bombs out. However, Crochet _does_ build on the NFS client _and_ when the source tree isn't in /usr/src which makes this issue very strange :-/ -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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"
Re: -current broken when src is on NFS
> On Jul 16, 2015, at 9:57 PM, O'Connor, Daniel wrote: > > >> On 16 Jul 2015, at 21:41, Rick Macklem wrote: >> r285066 fixed a POLA violation w.r.t. the old NFS client where the new >> client didn't return an EEXIST error return for symlink or mkdir to userland. >> The behaviour of not returning this error to userland (which was inherited >> from >> OpenBSD and was not the behaviour of the old FreeBSD NFS client but was >> default >> for the new NFS client) can be enabled via: >> vfs.nfs.ignore_eexist=1 >> >> You could try setting that sysctl and seeing if it makes any difference? >> >> That is the only recent change to the NFS client that *might* affect this. > > No dice :( > > It's pretty weird, it bombs out if either src or obj is on NFS.. > But even weirder is that if I build with crochet (a wrapper for cross > building to arm) it works. It doesn't work if I cross build manually and I > haven't been able to determine why crochet works yet. Crochet defaults MAKEOBJDIRPREFIX to ${WORKDIR}/obj if you have not already set it to something else. (This avoids cross-polluting the builds if you do regular manual cross-builds on the same machine.) If you’re having issues with /usr/obj being on NFS, that could be a factor. Tim ___ 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"
Re: -current broken when src is on NFS
> On 17 Jul 2015, at 14:27, O'Connor, Daniel wrote: >> On 16 Jul 2015, at 21:41, Rick Macklem wrote: >> r285066 fixed a POLA violation w.r.t. the old NFS client where the new >> client didn't return an EEXIST error return for symlink or mkdir to userland. >> The behaviour of not returning this error to userland (which was inherited >> from >> OpenBSD and was not the behaviour of the old FreeBSD NFS client but was >> default >> for the new NFS client) can be enabled via: >> vfs.nfs.ignore_eexist=1 >> >> You could try setting that sysctl and seeing if it makes any difference? >> >> That is the only recent change to the NFS client that *might* affect this. > > No dice :( > > It's pretty weird, it bombs out if either src or obj is on NFS.. > But even weirder is that if I build with crochet (a wrapper for cross > building to arm) it works. It doesn't work if I cross build manually and I > haven't been able to determine why crochet works yet. > > Relly frustraing :( So, it turns out NFS is not an issue.. I think it must be that it's not on /usr/src. I changed to building on the NFS server (which runs 10 but building -current should work OK) and it still bombs out. --- rescue.all__D --- make[5]: make[5]: don't know how to make /src/obj-amd64//src/FreeBSD-SVN/rescue/rescue//src/FreeBSD-SVN/bin/cat/cat.o. Stop That still doesn't explain how crochet and freebsd-wifi-build work though - I thought it was because they don't build rescue, but crochet does. Does anyone else see this? -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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"
Re: -current broken when src is on NFS
> On 16 Jul 2015, at 21:41, Rick Macklem wrote: > r285066 fixed a POLA violation w.r.t. the old NFS client where the new > client didn't return an EEXIST error return for symlink or mkdir to userland. > The behaviour of not returning this error to userland (which was inherited > from > OpenBSD and was not the behaviour of the old FreeBSD NFS client but was > default > for the new NFS client) can be enabled via: > vfs.nfs.ignore_eexist=1 > > You could try setting that sysctl and seeing if it makes any difference? > > That is the only recent change to the NFS client that *might* affect this. No dice :( It's pretty weird, it bombs out if either src or obj is on NFS.. But even weirder is that if I build with crochet (a wrapper for cross building to arm) it works. It doesn't work if I cross build manually and I haven't been able to determine why crochet works yet. Relly frustraing :( > To be honest, I have no idea what the correct behaviour for "//" in a > pathname is? Nothing, they just get eaten. This isn't AmigaDOS! :) -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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"
Re: -current broken when src is on NFS
Daniel O'Conner wrote: > I am seeing the following breakage when building -current and the source is > on NFS > > make -j 4 buildworld > ... > --- rescue.all__D --- > --- rescue --- > MAKEOBJDIRPREFIX=/usr/obj/src/FreeBSD-HEAD/rescue/rescue make -f rescue.mk > exe > --- sbin.all__D --- > --- pfctl_qstats.o --- > cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized > -Wstrict-prototypes -DENABLE_ALTQ -I/src/FreeBSD-HEAD/sbin/pfctl > -DWITH_INET6 -DWITH_INET -std=gnu99 -fstack-protector -Wsystem-headers > -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable > -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality > -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef > -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments > -c /src/FreeBSD-HEAD/sbin/pfctl/pfctl_qstats.c -o pfctl_qstats.o > --- rescue.all__D --- > --- cat_stub.c --- > echo "int _crunched_cat_stub(int argc, char **argv, char **envp){return > main(argc,argv,envp);}" >cat_stub.c > make[5]: make[5]: don't know how to make > /usr/obj/src/FreeBSD-HEAD/rescue/rescue//src/FreeBSD-HEAD/bin/cat/cat.o. > Stop > > make[5]: stopped in /usr/obj/src/FreeBSD-HEAD/rescue/rescue > *** [rescue] Error code 2 > r285066 fixed a POLA violation w.r.t. the old NFS client where the new client didn't return an EEXIST error return for symlink or mkdir to userland. The behaviour of not returning this error to userland (which was inherited from OpenBSD and was not the behaviour of the old FreeBSD NFS client but was default for the new NFS client) can be enabled via: vfs.nfs.ignore_eexist=1 You could try setting that sysctl and seeing if it makes any difference? That is the only recent change to the NFS client that *might* affect this. To be honest, I have no idea what the correct behaviour for "//" in a pathname is? rick > I copied this source tree to /usr/src (UFS) and it built fine - I guess it's > possible it is barfing on the path name but I figure someone else would have > noticed that. > > The NFS server is running 10.0-RELEASE and the NFS client is running -current > r285456, lockd is running and seems to be working (e.g., cat -l works) > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > ___ > 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" > ___ 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"