Re: CURRENT BROKEN fatal error: 'config_local.h' file not found

2016-02-16 Thread Bryan Drewery
On 2/16/16 2:55 AM, Outback Dingo wrote:
> seems current is broken due to a missing file
> /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error:
> 'config_local.h' file not found
> 


It's fixed now.


-- 
Regards,
Bryan Drewery
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)

2015-07-20 Thread Don Lewis
On 19 Jul, O'Connor, Daniel wrote:
 
 On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote:
 
 O'Connor, Daniel dar...@dons.net.au 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.
 
 Yeah the subject is wrong (I just updated it).
 
 I just did a build like so and it worked..
 env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld
 
 But this did not..
 make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64
 
 So, it seems MAKEOBJDIRPREFIX only works as an environmental variable
 - I wonder if there is a way the make system can be changed to warn
 about that?

At least it is documented in /usr/share/mk/bsd.obj.mk:

# MAKEOBJDIRPREFIX  Specifies somewhere other than /usr/obj to root the object
#   tree.  Note: MAKEOBJDIRPREFIX is an *environment* variable
#   and works properly only if set as an environment variable,
#   not as a global or command line variable!
#
#   E.g. use `env MAKEOBJDIRPREFIX=/somewhere/obj make'

Not the most obvious place to look ...

___
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 MAKEOBJDIRPREFIX is set (was: src is on NFS)

2015-07-20 Thread Navdeep Parhar
On Sun, Jul 19, 2015 at 11:05:48PM -0700, Don Lewis wrote:
 On 19 Jul, O'Connor, Daniel wrote:
  
  On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote:
  
  O'Connor, Daniel dar...@dons.net.au 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.
  
  Yeah the subject is wrong (I just updated it).
  
  I just did a build like so and it worked..
  env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld
  
  But this did not..
  make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64
  
  So, it seems MAKEOBJDIRPREFIX only works as an environmental variable
  - I wonder if there is a way the make system can be changed to warn
  about that?
 
 At least it is documented in /usr/share/mk/bsd.obj.mk:
 
 # MAKEOBJDIRPREFIX  Specifies somewhere other than /usr/obj to root the object
 #   tree.  Note: MAKEOBJDIRPREFIX is an *environment* variable
 #   and works properly only if set as an environment variable,
 #   not as a global or command line variable!
 #
 #   E.g. use `env MAKEOBJDIRPREFIX=/somewhere/obj make'
 
 Not the most obvious place to look ...

It is documented in build(7) too:

MAKEOBJDIRPREFIX  Defines the prefix for directory names in the tree of
built objects.  Defaults to /usr/obj if not defined.  This variable
should only be set in the environment and not via /etc/make.conf or the
command line.


Regards,
Navdeep
___
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 MAKEOBJDIRPREFIX is set (was: src is on NFS)

2015-07-19 Thread O'Connor, Daniel

 On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote:
 
 O'Connor, Daniel dar...@dons.net.au 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.

Yeah the subject is wrong (I just updated it).

I just did a build like so and it worked..
env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld

But this did not..
make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64

So, it seems MAKEOBJDIRPREFIX only works as an environmental variable - I 
wonder if there is a way the make system can be changed to warn about that?

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

2015-07-19 Thread Ian Lepore
On Sat, 2015-07-18 at 10:26 -0700, Simon J. Gerraty wrote:
 O'Connor, Daniel dar...@dons.net.au 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 MAKEOBJDIRPREFIX is set (was: src is on NFS)

2015-07-19 Thread Simon J. Gerraty
O'Connor, Daniel dar...@dons.net.au wrote:
  So, it seems MAKEOBJDIRPREFIX only works as an environmental variable

 Weird, I could have sworn I have set it on the command line and had it
 work, but..

In most normal usage you will likely not notice a difference.
It is only when a makefile is being clever that things go south when
you break its expectations.

  I thought there was a check in src/Makefile for that.
 
 Not so far as I can tell - it certainly gets quite far before blowing
 up with a non useful error message :)

The check in src/Makefile is only guarding against MAKEOBJDIRPREFIX set
in say make.conf, it explicitly discards the possibility of setting
MAKEOBJDIRPREFIX on command line - which seems wrong.

Also with bmake, you *can* usefully set MAKEOBJDIRPREFIX in a makefile
since the choice of .OBJDIR can be made after make starts reading
makefiles.

So the current test is perhaps out dated on that score too - though
only if something like auto.obj.mk is being used (-DWITH_AUTO_OBJ)
which I don't think I've tested with buildworld.
___
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 MAKEOBJDIRPREFIX is set (was: src is on NFS)

2015-07-19 Thread O'Connor, Daniel

 On 20 Jul 2015, at 04:29, Simon J. Gerraty s...@juniper.net wrote:
 O'Connor, Daniel dar...@dons.net.au wrote:
 
 But this did not..
 make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64
 
 Nor should it.
 There are several makefiles in the tree that expect to be able to 
 change MAKEOBJDIRPREFIX in the environment of a sub-make.
 When you set it on the command line like that you prevent such changes
 from working.

Ahh.. You learn something new every day :)

 So, it seems MAKEOBJDIRPREFIX only works as an environmental variable
 
 Yes, it has always been documented that way.

Weird, I could have sworn I have set it on the command line and had it work, 
but..

 - I wonder if there is a way the make system can be changed to warn
 about that?
 
 I thought there was a check in src/Makefile for that.

Not so far as I can tell - it certainly gets quite far before blowing up with a 
non useful error message :)

--
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 MAKEOBJDIRPREFIX is set (was: src is on NFS)

2015-07-19 Thread Simon J. Gerraty
O'Connor, Daniel dar...@dons.net.au wrote:
 Yeah the subject is wrong (I just updated it).
 
 I just did a build like so and it worked..
 env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld

That's the right way to use it.

 But this did not..
 make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64

Nor should it.
There are several makefiles in the tree that expect to be able to 
change MAKEOBJDIRPREFIX in the environment of a sub-make.
When you set it on the command line like that you prevent such changes
from working.

 So, it seems MAKEOBJDIRPREFIX only works as an environmental variable

Yes, it has always been documented that way.

 - I wonder if there is a way the make system can be changed to warn
 about that?

I thought there was a check in src/Makefile for that.
___
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

2015-07-19 Thread David Wolfskill
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

2015-07-19 Thread Simon J. Gerraty
 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 MAKEOBJDIRPREFIX is set (was: src is on NFS)

2015-07-19 Thread O'Connor, Daniel

 On 20 Jul 2015, at 11:40, Simon J. Gerraty s...@juniper.net wrote:
 
 O'Connor, Daniel dar...@dons.net.au wrote:
 So, it seems MAKEOBJDIRPREFIX only works as an environmental variable
 
 Weird, I could have sworn I have set it on the command line and had it
 work, but..
 
 In most normal usage you will likely not notice a difference.
 It is only when a makefile is being clever that things go south when
 you break its expectations.

I guess, buildworld is pretty clever though :)

 I thought there was a check in src/Makefile for that.
 
 Not so far as I can tell - it certainly gets quite far before blowing
 up with a non useful error message :)
 
 The check in src/Makefile is only guarding against MAKEOBJDIRPREFIX set
 in say make.conf, it explicitly discards the possibility of setting
 MAKEOBJDIRPREFIX on command line - which seems wrong.
 
 Also with bmake, you *can* usefully set MAKEOBJDIRPREFIX in a makefile
 since the choice of .OBJDIR can be made after make starts reading
 makefiles.
 
 So the current test is perhaps out dated on that score too - though
 only if something like auto.obj.mk is being used (-DWITH_AUTO_OBJ)
 which I don't think I've tested with buildworld.

I know sod all about *make but as an 'end user' a seat belt to warn about this 
problem would be Really Nice (tm).

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

2015-07-18 Thread Simon J. Gerraty
O'Connor, Daniel dar...@dons.net.au 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

2015-07-17 Thread O'Connor, Daniel

 On 18 Jul 2015, at 13:59, Tim Kientzle t...@kientzle.com 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

2015-07-17 Thread Tim Kientzle

 On Jul 16, 2015, at 9:57 PM, O'Connor, Daniel dar...@dons.net.au wrote:
 
 
 On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca 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

2015-07-17 Thread O'Connor, Daniel

 On 17 Jul 2015, at 14:27, O'Connor, Daniel dar...@dons.net.au wrote:
 On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca 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

2015-07-16 Thread Rick Macklem
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


Re: -current broken when src is on NFS

2015-07-16 Thread O'Connor, Daniel

 On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca 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 on r246222?

2013-02-04 Thread John Baldwin
On Sunday, February 03, 2013 11:26:53 am O. Hartmann wrote:
 CURRENT, as of recent Revision 246285 (see below) fails and
 crashes/reboots on an Ivy-Bridge platform (see below). Since the box
 does not have debugging switched on (not yet, will do eventually
 Monday), Last thing I see on screen is
 
 p4tcc3: CPU Frequency Thermal Control on cpu3
 
 then the system run dark and reboots without any notice (kernel doesn't
 have debugging switched on so far, will do this after Monday).

I don't think there are any known issues.  Can you narrow it down to a
specific commit?

-- 
John Baldwin
___
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 on r246222?

2013-02-04 Thread O. Hartmann
Am 02/04/13 20:50, schrieb John Baldwin:
 On Sunday, February 03, 2013 11:26:53 am O. Hartmann wrote:
 CURRENT, as of recent Revision 246285 (see below) fails and
 crashes/reboots on an Ivy-Bridge platform (see below). Since the box
 does not have debugging switched on (not yet, will do eventually
 Monday), Last thing I see on screen is

 p4tcc3: CPU Frequency Thermal Control on cpu3

 then the system run dark and reboots without any notice (kernel doesn't
 have debugging switched on so far, will do this after Monday).
 
 I don't think there are any known issues.  Can you narrow it down to a
 specific commit?
 

No, I can't. But I can now confirm, that with  r246326 the problem has gone.

Oliver



signature.asc
Description: OpenPGP digital signature


Re: -current broken in acpi/iasl

2013-01-18 Thread Sergey V. Dyatko
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:

 === usr.sbin/acpi/iasl (all)
 cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
 -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
 -Wno-uninitialized -Wno-pointer-sign -c
 /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c
 cc1: warnings being treated as errors
 /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:
 In function 'AcpiDmIsResourceTemplate':
 /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419:
 warning: dereferencing type-punned pointer will break strict-aliasing
 rules *** [dmresrc.o] Error code 1
 
 Stop in /usr/src/usr.sbin/acpi/iasl.
 *** [all] Error code 1
 

according to rumors buildworld done successfully with the clang. But I
didn't test it. Look at buildworld is broken ? thread 


-- 
wbr, tiger
___
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 in acpi/iasl

2013-01-18 Thread David Wolfskill
On Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote:
 On Fri, 18 Jan 2013 22:17:27 +0400
 Andrey Chernov a...@freebsd.org wrote:
 
  === usr.sbin/acpi/iasl (all)
  cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
  -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
  -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
  -Wno-uninitialized -Wno-pointer-sign -c
  /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c
  cc1: warnings being treated as errors
  /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:
  In function 'AcpiDmIsResourceTemplate':
  /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419:
  warning: dereferencing type-punned pointer will break strict-aliasing
  rules *** [dmresrc.o] Error code 1
  
  Stop in /usr/src/usr.sbin/acpi/iasl.
  *** [all] Error code 1
  
 
 according to rumors buildworld done successfully with the clang. But I
 didn't test it. Look at buildworld is broken ? thread 
 ...

My head (10.0-CURRENT) builds (on my laptop  build machine) were
uneventful; e.g.:

FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #796  
r245584M/245600: Fri Jan 18 06:07:23 PST 2013 
r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY  i386

And yes, I use clang.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpCfXU5Sqs2v.pgp
Description: PGP signature


Re: -current broken in acpi/iasl

2013-01-18 Thread John-Mark Gurney
Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34 +0300:
 On Fri, 18 Jan 2013 22:17:27 +0400
 Andrey Chernov a...@freebsd.org wrote:
 
  === usr.sbin/acpi/iasl (all)
  cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
  -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
  -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
  -Wno-uninitialized -Wno-pointer-sign -c
  /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c
  cc1: warnings being treated as errors
  /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:
  In function 'AcpiDmIsResourceTemplate':
  /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419:
  warning: dereferencing type-punned pointer will break strict-aliasing
  rules *** [dmresrc.o] Error code 1
  
  Stop in /usr/src/usr.sbin/acpi/iasl.
  *** [all] Error code 1
  
 
 according to rumors buildworld done successfully with the clang. But I
 didn't test it. Look at buildworld is broken ? thread 

Looks like this broken when jkim imported the latest ACPICA code base:
https://svnweb.freebsd.org/base?view=revisionrevision=245582

I've forward the tinderbox failure to him, so hopefully he'll fix it
shortly...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
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 in acpi/iasl

2013-01-18 Thread Andrey Chernov
On 18.01.2013 22:37, David Wolfskill wrote:
 On Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote:
 On Fri, 18 Jan 2013 22:17:27 +0400
 Andrey Chernov a...@freebsd.org wrote:

 === usr.sbin/acpi/iasl (all)
 cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
 -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
 -Wno-uninitialized -Wno-pointer-sign -c
 /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c
 cc1: warnings being treated as errors
 /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:
 In function 'AcpiDmIsResourceTemplate':
 /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419:
 warning: dereferencing type-punned pointer will break strict-aliasing
 rules *** [dmresrc.o] Error code 1

 Stop in /usr/src/usr.sbin/acpi/iasl.
 *** [all] Error code 1


 according to rumors buildworld done successfully with the clang. But I
 didn't test it. Look at buildworld is broken ? thread 
 ...
 
 My head (10.0-CURRENT) builds (on my laptop  build machine) were
 uneventful; e.g.:
 
 FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #796  
 r245584M/245600: Fri Jan 18 06:07:23 PST 2013 
 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY  i386
 
 And yes, I use clang.
 
 Peace,
 david
 

I have no clang bloat, it happens with good old gcc.




signature.asc
Description: OpenPGP digital signature


Re: -current broken in acpi/iasl

2013-01-18 Thread Jung-uk Kim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2013-01-18 13:39:01 -0500, John-Mark Gurney wrote:
 Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34
 +0300:
 On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov
 a...@freebsd.org wrote:
 
 === usr.sbin/acpi/iasl (all) cc -O2 -pipe -march=core2
 -DACPI_ASL_COMPILER -I. 
 -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 
 -fstack-protector -Wsystem-headers -Werror -Wall
 -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c 
 /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c

 
cc1: warnings being treated as errors
 /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:

 
In function 'AcpiDmIsResourceTemplate':
 /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419:

 
warning: dereferencing type-punned pointer will break strict-aliasing
 rules *** [dmresrc.o] Error code 1
 
 Stop in /usr/src/usr.sbin/acpi/iasl. *** [all] Error code 1
 
 
 according to rumors buildworld done successfully with the clang.
 But I didn't test it. Look at buildworld is broken ? thread
 
 Looks like this broken when jkim imported the latest ACPICA code
 base: 
 https://svnweb.freebsd.org/base?view=revisionrevision=245582
 
 I've forward the tinderbox failure to him, so hopefully he'll fix
 it shortly...

It should be fixed now (r245636).  Sorry for the breakage.

Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)

iQEcBAEBAgAGBQJQ+esDAAoJECXpabHZMqHOypgIAILl0S2cvEdTQWXJ4PWase07
yKA+DPHYAUx09JHbnLfEeA+KLFUz2jnX7dYR9ohSMcsnkI1/AH/z8dkFc3NLPUQw
TXh1edQyXaYr0WK+3sW81Tl5thka5VwjznoJj1r/Og8Nrx/xYUYCEtpPsjDU1hW0
8T897m6MqOSZokWs4dyOt1ZWoncGRTHgC5tCzjcmAuiOTIkZ7hdLNXKu1nm+cgcy
LNEvJf/d1bz6UzQ9xxCxG+HttZhi4YL8uAAYMHZtydM+Zp5yZskajyNmDkThSMhu
LrUohDfMLk84DkyoAfzojr90o8tk6TujfHR+osF3oj9NkDi6o6VK0AVs1yKPg5c=
=poDO
-END PGP SIGNATURE-
___
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 in lukemftpd

2002-03-01 Thread David Wolfskill

From: Poul-Henning Kamp [EMAIL PROTECTED]
Date: Fri, 01 Mar 2002 15:07:48 +0100

/flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:324: size of ar
ray `remotehost' has non-integer type
/flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:327: syntax err
or before `transflag'
...

Confirmed.  Looks as if setjmp.h (at least) was intended to have
been #included (somehow), but wasn't.

It's #included by contrib/lukemftpd/lukemftpd.h, but lukemftpd.h doesn't
seem to be #included from anything in ls-unmain.c.

Cheers,
david   (links to my resume at http://www.catwhisker.org/~david)
-- 
David H. Wolfskill  [EMAIL PROTECTED]
I believe it would be irresponsible (and thus, unethical) for me to advise,
recommend, or support the use of any product that is or depends on any
Microsoft product for any purpose other than personal amusement.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: current broken ?

2001-12-06 Thread Dag-Erling Smorgrav

Niels Chr. Bank-Pedersen [EMAIL PROTECTED] writes:
 On Thu, Dec 06, 2001 at 02:26:31AM +0100, Martin Heller wrote:
  The 'make buildworld' stops  while doing the 'make depend'-stage in the
  usr.sbin/keyserv/ directory with an 'Error 2' .
  Sources 2h old , current system 24h.
 I think the breakage is actually pam related and occurs in
 usr.bin/login:

This has been fixed.  I didn't catch it in pre-commit tests due to
source tree pollution.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: current broken ?

2001-12-05 Thread Niels Chr. Bank-Pedersen

On Thu, Dec 06, 2001 at 02:26:31AM +0100, Martin Heller wrote:
 The 'make buildworld' stops  while doing the 'make depend'-stage in the
 usr.sbin/keyserv/ directory with an 'Error 2' .
 Sources 2h old , current system 24h.

I think the breakage is actually pam related and occurs in
usr.bin/login:

  === usr.bin/login
  cd /usr/src/usr.sbin/gifconfig; make _EXTRADEPEND
  echo gifconfig: /usr/obj/usr/src/i386/usr/lib/libc.a   .depend
  === usr.sbin/ifmcstat
  rm -f .depend
  mkdep -f .depend -a-DLOGIN_ACCESS -DLOGALL -I/usr/obj/usr/src/i386/usr/include  
/usr/src/usr.bin/login/login.c /usr/src/usr.bin/login/login_access.c /
  usr/src/usr.bin/login/login_fbtab.c
  cd /usr/src/gnu/usr.bin/cc/c++filt; make _EXTRADEPEND
  rm -f .depend
  mkdep -f .depend -a-I/usr/obj/usr/src/i386/usr/include  
/usr/src/usr.sbin/ifmcstat/ifmcstat.c
  echo c++filt: /usr/obj/usr/src/i386/usr/lib/libc.a   .depend
  === gnu/usr.bin/cc/doc
  In file included from /usr/src/usr.bin/login/login.c:78:
  /usr/obj/usr/src/i386/usr/include/security/pam_misc.h:10: security/pam_client.h: No 
such file or directory
  cd /usr/src/usr.sbin/ifmcstat; make _EXTRADEPEND
  echo ifmcstat: /usr/obj/usr/src/i386/usr/lib/libc.a 
/usr/obj/usr/src/i386/usr/lib/libkvm.a  .depend
  === usr.sbin/inetd
  === gnu/usr.bin/cc/cc1obj
  mkdep: compile failed
  *** Error code 1
  1 error
  *** Error code 2
  1 error
  *** Error code 2

It appears that pam_client.h isn't pulled in from libpamc/include/security


/Niels Chr.

-- 
 Niels Christian Bank-Pedersen, NCB1-RIPE.

 Hey, are any of you guys out there actually *using* RFC 2549?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: current broken ?

2001-12-05 Thread Jun Kuriyama


My log is:

=== usr.bin/login
rm -f .depend
mkdep -f .depend -a-DLOGIN_ACCESS -DLOGALL -I/usr/obj/usr/src/i386/usr/include  
/usr/src/usr.bin/login/login.c /usr/src/usr.bin/login/login_access.c 
/usr/src/usr.bin/login/login_fbtab.c
In file included from /usr/src/usr.bin/login/login.c:78:
/usr/obj/usr/src/i386/usr/include/security/pam_misc.h:10: security/pam_client.h: No 
such file or directory
mkdep: compile failed
*** Error code 1

Stop in /usr/src/usr.bin/login.


-- 
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: -current broken in pcic_pci.c

2001-08-27 Thread Warner Losh

In message [EMAIL PROTECTED] Harti Brandt writes:
: Version 1.83 of that file breaks the GENERIC build. You probably meant to
: write:

Just fixed.

Warner

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: -current broken ?

2001-05-28 Thread Joerg Wunsch

Poul-Henning Kamp [EMAIL PROTECTED] wrote:

 
 === usr.bin/fetch

 /flat/src/usr.bin/fetch/fetch.c: In function `main':
 /flat/src/usr.bin/fetch/fetch.c:757: `vtty' undeclared (first use in this function)

Noticed this in my `make release' attempt yesterday, too.

-- 
cheers, Jorg   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: -current broken ?

2001-05-28 Thread Sheldon Hearn



On Mon, 28 May 2001 21:45:02 +0200, Joerg Wunsch wrote:

  === usr.bin/fetch
 
  /flat/src/usr.bin/fetch/fetch.c: In function `main':
  /flat/src/usr.bin/fetch/fetch.c:757: `vtty' undeclared (first use in this function)
 
 Noticed this in my `make release' attempt yesterday, too.

Fixed in rev 1.30 of fetch.c.

Ciao,
Sheldon.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: -CURRENT broken in gnu/usr.bin/perl/perl

2001-05-02 Thread Anton Berezin

On Wed, May 02, 2001 at 08:27:36AM -0700, David Wolfskill wrote:

 Just glanced through cvs-all; didn't see commits more recent than my last
 CVSup:
 
 CVSup started from cvsup14.freebsd.org at Tue May  1 03:47:00 PDT 2001
 CVSup ended from cvsup14.freebsd.org at Tue May  1 03:55:45 PDT 2001

Did you do another buildworld between these CVSup's?

 CVSup started from cvsup14.freebsd.org at Wed May  2 03:47:00 PDT 2001
 CVSup ended from cvsup14.freebsd.org at Wed May  2 03:53:01 PDT 2001

The suspected commit is

   [EMAIL PROTECTED]

It looks like the recent BSDPAN change has a problem - I am looking into
it.

 The error occurred during stage 4: make dependencies:
 
 === gnu/usr.bin/perl/libperl
 === gnu/usr.bin/perl/perl
 Extracting config.h (with variable substitutions)
 Extracting cflags (with variable substitutions)
 Extracting writemain (with variable substitutions)
 Extracting myconfig (with variable substitutions)
 Missing right curly or square bracket at lib/SelfLoader.pm line 69, at end of line
 syntax error at lib/SelfLoader.pm line 69, at EOF
 Compilation failed in require at /usr/libdata/perl/BSDPAN/BSDPAN/Override.pm line 17.
 Compilation failed in require at /usr/libdata/perl/BSDPAN/Config.pm line 37.
 BEGIN failed--compilation aborted at /usr/libdata/perl/BSDPAN/Config.pm line 37.
 Compilation failed in require at 
/usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5/configpm line 430.
 *** Error code 255
 
 Stop in /usr/src/gnu/usr.bin/perl/perl.
 *** Error code 1
 
 
 Hmm  SelfLoader.pm was last modified:
 m133[3] ls -l SelfLoader.pm 
 -rw-rw-r--  1 david  wheel  12043 Jun 25  2000 SelfLoader.pm
 
 It's at revision 1.1
 
 Hmmm...,

Cheers,
+Anton.
-- 
May the tuna salad be with you.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: -CURRENT broken in gnu/usr.bin/perl/perl

2001-05-02 Thread David Wolfskill

Date: Wed, 2 May 2001 18:28:18 +0200
From: Anton Berezin [EMAIL PROTECTED]

 CVSup started from cvsup14.freebsd.org at Tue May  1 03:47:00 PDT 2001
 CVSup ended from cvsup14.freebsd.org at Tue May  1 03:55:45 PDT 2001

Did you do another buildworld between these CVSup's?

 CVSup started from cvsup14.freebsd.org at Wed May  2 03:47:00 PDT 2001
 CVSup ended from cvsup14.freebsd.org at Wed May  2 03:53:01 PDT 2001


Yes.  Built OK; seemed to run OK (though I mostly run -STABLE on the
box).

The suspected commit is

   [EMAIL PROTECTED]

It looks like the recent BSDPAN change has a problem - I am looking into
it.

OK; thanks!

Cheers,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: -CURRENT broken in gnu/usr.bin/perl/perl

2001-05-02 Thread Anton Berezin

On Wed, May 02, 2001 at 06:28:18PM +0200, Anton Berezin wrote:
 On Wed, May 02, 2001 at 08:27:36AM -0700, David Wolfskill wrote:

 It looks like the recent BSDPAN change has a problem - I am looking into
 it.

  The error occurred during stage 4: make dependencies:
  
  === gnu/usr.bin/perl/libperl
  === gnu/usr.bin/perl/perl
  Extracting config.h (with variable substitutions)
  Extracting cflags (with variable substitutions)
  Extracting writemain (with variable substitutions)
  Extracting myconfig (with variable substitutions)
  Missing right curly or square bracket at lib/SelfLoader.pm line 69, at end of line
  syntax error at lib/SelfLoader.pm line 69, at EOF
  Compilation failed in require at /usr/libdata/perl/BSDPAN/BSDPAN/Override.pm line 
17.
  Compilation failed in require at /usr/libdata/perl/BSDPAN/Config.pm line 37.
  BEGIN failed--compilation aborted at /usr/libdata/perl/BSDPAN/Config.pm line 37.
  Compilation failed in require at 
/usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5/configpm line 430.
  *** Error code 255
  
  Stop in /usr/src/gnu/usr.bin/perl/perl.
  *** Error code 1

The fix has been committed.  Please also see a HEADS UP message on this
list.

Thanks, David, for reporting this.

+Anton.
-- 
May the tuna salad be with you.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: -current broken, or am I?

2001-03-15 Thread David Wolfskill

Date: Thu, 15 Mar 2001 15:52:45 -0500
From: Michael Lucas [EMAIL PROTECTED]

Is it just me?

[breakage elided -- dhw]

Stop in /usr/src/usr.bin/kdump.
*** Error code 1




Didn't happen for me; CVSup started at 23:47 yesterday, completed at
Thu Mar 15 01:09:38 PST 2001.

Built just fine; runs OK as far as I can tell.

Cheers,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: -current broken, or am I?

2001-03-15 Thread Soren Schmidt

It seems Andrzej Tobola wrote:
 
  Make that me too ...
 
 I diagnosed problem - sys/sys/ata.h commited by sos is probably the culprit:

Its fixed, sorry, too many source trees here...

-Sren

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: possibly related data point - (was) Re: Current Broken!

2000-12-10 Thread Bruce Evans

On Thu, 7 Dec 2000 [EMAIL PROTECTED] wrote:

 I'm not a constraints expert either, but I noticed that when I try to
 build a kernel WITHOUT any optimization, I get a failure in
 
 /usr/src/sys/i386/atomic.h .
 
 # make atomic.o
 cc -c -O0 -pipe -Wall -Wredundant-decls -Wnested-externs
 ...
 /usr/src/sys/i386/i386/atomic.c
 In file included from /usr/src/sys/i386/i386/atomic.c:48:
 machine/atomic.h: In function `atomic_set_char':
 machine/atomic.h:178: inconsistent operand constraints in an `asm'

 with any optimization, eg -O, there is _NO_ error. Makes me think the optimizer
 is optimizing out the offending contraints.  Ouch. Probably not what was intended.
 
 Maybe this is what's biting you ?

This is sort of the opposite of the bug in machine/mutex.h.  It is
believed to be caused by using the operand-number constraints (e.g.,
"(0)") to declare input-output operands in machine/atomic.h.
Input-output operands and/or these constraints apparently never worked
right until a recent versions of gcc introduced the "+" contraint to
declare input-output operations properly.  machine/atomic.h uses the
new constraint.  The problem seems to be that "+" contraints don't
work right either.

The following kludge fixes compilation of cam_periph.c:

diff -c2 mutex.h~ mutex.h
*** mutex.h~Sun Dec 10 19:28:53 2000
--- mutex.h Sun Dec 10 23:50:21 2000
***
*** 171,174 
--- 176,180 
\
__asm __volatile (  \
+ " movl$" _V(MTX_UNOWNED) ",%%eax;"\
  " " MPLOCKED ""   \
  " cmpxchgl %4,%0;"/* try easy rel */  \
***
*** 181,185 
  "# exitlock_norecurse"\
: "+m" (mtxp-mtx_lock),/* 0 */ \
! "+a" (_tid)   /* 1 */ \
: "gi" (type),  /* 2 (input) */ \
  "g" (mtxp),   /* 3 */ \
--- 187,191 
  "# exitlock_norecurse"\
: "+m" (mtxp-mtx_lock),/* 0 */ \
! "=a" (_tid)  /* 1 */ \
: "gi" (type),  /* 2 (input) */ \
  "g" (mtxp),   /* 3 */ \

This bug seems to have been encountered before -- I copied this inferior
code from the function before the one that doesn't compile.  Several other
functions in machine/mutex.h also use it.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: possibly related data point - (was) Re: Current Broken!

2000-12-10 Thread Bruce Evans

On Fri, 8 Dec 2000, John Baldwin wrote:

 On 08-Dec-00 [EMAIL PROTECTED] wrote:
  
  John,
  
  I'm not a constraints expert either, but I noticed that when I try to
  build a kernel WITHOUT any optimization, I get a failure in
  
  /usr/src/sys/i386/atomic.h .
 
 Compiling a kernel with anything but -O for optimization is not supported.  gcc
 has produced buggy code for the -O0 case in the past.

-O0 (or plain cc without -O) is supposed to work, but no one cares enough
about it to fix it every day.  Fixing machine/atomic.h has been pending
for many days now.  My oldest saved mail about it is dated 21 July 2000,
but ISTR discussing it last year.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: possibly related data point - (was) Re: Current Broken!

2000-12-08 Thread John Baldwin


On 08-Dec-00 [EMAIL PROTECTED] wrote:
 
 John,
 
 I'm not a constraints expert either, but I noticed that when I try to
 build a kernel WITHOUT any optimization, I get a failure in
 
 /usr/src/sys/i386/atomic.h .

Compiling a kernel with anything but -O for optimization is not supported.  gcc
has produced buggy code for the -O0 case in the past.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: possibly related data point - (was) Re: Current Broken!

2000-12-08 Thread atrens


I hit on it by accident (I normally compile with -O). That said, your
claim that gcc with no optimization generates incorrect code is
kind of counter-intuitive, wouldn't you say ?

I think you missed my point, I was just illustrating that optimizer seems
to affect (in my case apparently negate) the processing of constraints.

What you take from that is up to you - I was just trying to be helpful :)

Cheers,

A.

+--
| Andrew Atrens Nortel Networks, Ottawa, Canada. |
| All opinions expressed are my own,  not those of any employer. |
   --+
 Berkeley had what we called "copycenter", which is "take it down
 to the copy center and make as many copies as you want".
 -- Kirk McKusick
+----+






To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Current Locking up... Re: possibly related data point - (was) Re: Current Broken!

2000-12-08 Thread Steven E. Ames

-CURRENT as of yesterday was still causing my system to lock (with
'make -j8 world'). Lock=no possibility of debugger.

I have two of these systems and they behave identically. If someone with
lots more debugging experience would benefit from borrowing one of the
machines I'd happily send it to you. I'd really like to be use SMP
stabily.

-Steve

- Original Message -
From: "John Baldwin" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; "Andrew
[SKY:ET95:EXCH]" [EMAIL PROTECTED]
Sent: Friday, December 08, 2000 1:49 PM
Subject: RE: possibly related data point - (was) Re: Current Broken!



 On 08-Dec-00 [EMAIL PROTECTED] wrote:
 
  I hit on it by accident (I normally compile with -O). That said,
your
  claim that gcc with no optimization generates incorrect code is
  kind of counter-intuitive, wouldn't you say ?

 I've seen it do weird things with -O0 (mostly with C++). :)  It's just
another
 program.  Nothing is keeping it from having bugs. :)

  I think you missed my point, I was just illustrating that optimizer
seems
  to affect (in my case apparently negate) the processing of
constraints.

 I am back now to thinking that it is a gcc bug in the -O case now as
well.  The
 constraings I removed were in fact valid, so I've put them back in,
but just
 disabled the macros for now until gcc is fixed.

  What you take from that is up to you - I was just trying to be
helpful :)

 Sorry if I came across as if I was biting your head off, that was not
the
 intent.

  Cheers,
 
  A.

 --

 John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
 PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc
 "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: possibly related data point - (was) Re: Current Broken!

2000-12-08 Thread John Baldwin


On 08-Dec-00 [EMAIL PROTECTED] wrote:
 
 I hit on it by accident (I normally compile with -O). That said, your
 claim that gcc with no optimization generates incorrect code is
 kind of counter-intuitive, wouldn't you say ?

I've seen it do weird things with -O0 (mostly with C++). :)  It's just another
program.  Nothing is keeping it from having bugs. :)

 I think you missed my point, I was just illustrating that optimizer seems
 to affect (in my case apparently negate) the processing of constraints.

I am back now to thinking that it is a gcc bug in the -O case now as well.  The
constraings I removed were in fact valid, so I've put them back in, but just
disabled the macros for now until gcc is fixed.

 What you take from that is up to you - I was just trying to be helpful :)

Sorry if I came across as if I was biting your head off, that was not the
intent.

 Cheers,
 
 A.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



possibly related data point - (was) Re: Current Broken!

2000-12-07 Thread atrens


John,

I'm not a constraints expert either, but I noticed that when I try to
build a kernel WITHOUT any optimization, I get a failure in

/usr/src/sys/i386/atomic.h .

# make atomic.o
cc -c -O0 -pipe -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -fformat-extensions -ansi  -nostdinc -I-  -I. -I/usr/src/sys
-I/usr/src/sys/../include
-I/usr/src/sys/contrib/dev/acpica/Subsystem/Include  -D_KERNEL -include
opt_global.h -elf  -mpreferred-stack-boundary=2 -fomit-frame-pointer
/usr/src/sys/i386/i386/atomic.c
In file included from /usr/src/sys/i386/i386/atomic.c:48:
machine/atomic.h: In function `atomic_set_char':
machine/atomic.h:178: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_clear_char':
machine/atomic.h:179: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_add_char':
machine/atomic.h:180: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_subtract_char':
machine/atomic.h:181: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_set_short':
machine/atomic.h:183: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_clear_short':
machine/atomic.h:184: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_add_short':
machine/atomic.h:185: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_subtract_short':
machine/atomic.h:186: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_set_int':
machine/atomic.h:188: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_clear_int':
machine/atomic.h:189: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_add_int':
machine/atomic.h:190: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_subtract_int':
machine/atomic.h:191: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_set_long':
machine/atomic.h:193: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_clear_long':
machine/atomic.h:194: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_add_long':
machine/atomic.h:195: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_subtract_long':
machine/atomic.h:196: inconsistent operand constraints in an `asm'
*** Error code 1

with any optimization, eg -O, there is _NO_ error. Makes me think the optimizer
is optimizing out the offending contraints.  Ouch. Probably not what was intended.

Maybe this is what's biting you ?

I cut and pasted the cc command, inserted a -E, removed the #line
directives, and captured the offending lines - since my mailer doesn't
like really long lines, I've folded them - each function previously
occupied a single line.

void
atomic_set_char (volatile u_char  *p, u_char  v){
__asm volatile (  "orb %b2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}

void
atomic_clear_char (volatile u_char  *p, u_char  v){
__asm volatile ( "andb %b2,%0" : "=m" (*p) :  "0" (*p), "ir" ( ~v ));
}

void
atomic_add_char (volatile u_char  *p, u_char  v){
__asm volatile ( "addb %b2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}

void
atomic_subtract_char (volatile u_char  *p, u_char  v){
__asm volatile ("subb %b2,%0" : "=m" (*p) :  "0" (*p),  "ir" ( v ));
}

void
atomic_set_short (volatile u_short  *p, u_short  v){
__asm volatile ("orw %w2,%0" : "=m" (*p) :  "0" (*p), "ir"  ( v ));
}

void
atomic_clear_short (volatile u_short  *p, u_short  v){
__asm volatile ("andw %w2,%0"  : "=m" (*p) : "0" (*p), "ir" ( ~v ));
}

void atomic_add_short (volatile u_short  *p, u_short  v){
__asm volatile ("addw %w2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_subtract_short (volatile u_short  *p, u_short  v){
__asm volatile ("subw %w2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_set_int (volatile u_int  *p, u_int  v){
__asm volatile ("orl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_clear_int (volatile u_int  *p, u_int  v){
__asm volatile ("andl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( ~v ));
}

void atomic_add_int (volatile u_int  *p, u_int  v){
   __asm volatile ("addl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_subtract_int (volatile u_int  *p, u_int  v){
__asm volatile ("subl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_set_long (volatile u_long  *p, u_long  v){
__asm volatile ("orl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_clear_long (volatile u_long  *p, u_long  v){
__asm volatile ("andl %2,%0" : "=m" (*p) :  "0" (*p), "ir" (  ~v ));
}

void atomic_add_long (volatile u_long  *p, u_long  v){
__asm volatile ("addl %2,%0" : "=m" (*p) :  "0" (*p), "ir" ( v ));
}

void atomic_subtract_long (volatile u_long  *p, u_long  

Re: Current broken in ncurses ?

2000-07-21 Thread Doug Barton

On Fri, 21 Jul 2000, Ollivier Robert wrote:

 Am I the only one with this ?
 
 cc -O -pipe -I. -I/src/src/lib/libncurses 
-I/src/src/lib/libncurses/../../contrib/ncurses/ncurses 
-I/src/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE 
-DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -I/net/nas/roberto/sidhe/src/src/i386/usr/include 
-c /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c -o 
comp_scan.o
 /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c: In function 
`_nc_get_token':
 /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: 
`_nc_disable_period' undeclared (first use in this function)
 /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: (Each 
undeclared identifier is reported only once
 /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: for 
each function it appears in.)
 *** Error code 1
 
 Stop in /src/src/lib/libncurses.

I just completed a make world here... try the usual cleaning
/usr/obj and make cleandir in src and see if that helps. 

Good luck,

Doug
-- 
"Live free or die"
- State motto of my ancestral homeland, New Hampshire

Do YOU Yahoo!?




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: -current broken?

1999-08-18 Thread Poul-Henning Kamp


I saw that yesterday, and fixed it by:

cd /usr/src
make includes
cd /sys/i386/conf
config -r CRITTER
cd ../../compile/CRITTER
make depend
make

In message [EMAIL PROTECTED], Christopher Masto writes:
Yesterday and today, after a cvsup and kernel build, I get a panic
very early in the boot on my laptop.  What's left on the screen is a
general protection fault in kernel mode, and an attempt to trace just
causes another panic.  Tomorrow I will put a serial cable on it and
get some details, but I'm guessing that this comes from the recent
BUF_STRATEGY stuff, possibly breaking in the wd driver (which might
be why there hasn't been a report yet if most everyone is using ata).

I'm stuck with wd for the moment (pccard compact flash stuff), so if
that's it and it hasn't been repaired by then, I'll dig into it.
-- 
Christopher Masto Senior Network Monkey  NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message


--
Poul-Henning Kamp FreeBSD coreteam member
[EMAIL PROTECTED]   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message