Problem with buildworld: what is major really supposed to be?
Trying to make buildworld for today's -CURRENT, I get:
stage 4: building libraries
--
...
=== doc
cc -fpic -DPIC -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c
/usr/src/lib/libkvm/kvm_file.c -o kvm_file.So
In file included from /usr/obj/usr/src/i386/usr/include/sys/file.h:40,
from /usr/src/lib/libkvm/kvm_file.c:54:
/usr/obj/usr/src/i386/usr/include/sys/systm.h:305: syntax error before `int'
/usr/obj/usr/src/i386/usr/include/sys/systm.h:306: syntax error before `int'
/usr/obj/usr/src/i386/usr/include/sys/systm.h:307: syntax error before `('
*** Error code 1
After enough tinkering with copies of the files to demonstrate to
my satisfaction that my C skills are pretty rusty, I noticed that:
* The lines in systm.h look like (starting at line 301):
/*
* Common `dev_t' stuff are declared here to avoid #include poisoning
*/
int major(dev_t x);
int minor(dev_t x);
dev_t makedev(int x, int y);
udev_t dev2udev(dev_t x);
dev_t udev2dev(udev_t x, int b);
int uminor(udev_t dev);
int umajor(udev_t dev);
udev_t makeudev(int x, int y);
so it looks as if we're declaring major as a function returning int.
* But sys/sys/file.h, starting at line 49 reads:
#ifdef _KERNEL
#include sys/types.h
#include sys/queue.h
#include sys/_lock.h
#include sys/_mutex.h
which is OK, except that sys/sys/types.h, starting at line 113 reads:
/*
* minor() gives a cookie instead of an index since we don't want to
* change the meanings of bits 0-15 or waste time and space shifting
* bits 16-31 for devices that don't use them.
*/
#define major(x)((int)(((u_int)(x) 8)0xff)) /* major number */
#define minor(x)((int)((x)0x00ff)) /* minor number */
#define makedev(x,y)((dev_t)(((x) 8) | (y))) /* create dev_t */
and this appears to be a bit of a problem, because by the time the C
compiler gets to the int major(dev_t x); line in sys/sys/systm.h,
major has been replaced, so the line looks like:
int ((int)(((u_int)( dev_t x ) 8)0xff)) ;
which is pretty non-ideal, any way you look at it.
In case it's of interest/value, recent CVSup history is:
freebeast(5.0-C)[44] tail /var/log/cvsup-history.log
CVSup begin from cvsup14.freebsd.org at Tue Feb 19 03:47:02 PST 2002
CVSup ended from cvsup14.freebsd.org at Tue Feb 19 03:53:36 PST 2002
CVSup begin from cvsup14.freebsd.org at Wed Feb 20 03:47:02 PST 2002
CVSup ended from cvsup14.freebsd.org at Wed Feb 20 04:00:08 PST 2002
CVSup begin from cvsup14.freebsd.org at Thu Feb 21 03:47:03 PST 2002
CVSup ended from cvsup14.freebsd.org at Thu Feb 21 03:53:29 PST 2002
CVSup begin from cvsup14.freebsd.org at Fri Feb 22 03:47:02 PST 2002
CVSup ended from cvsup14.freebsd.org at Fri Feb 22 03:54:26 PST 2002
CVSup begin from cvsup14.freebsd.org at Sat Feb 23 04:35:13 PST 2002
CVSup ended from cvsup14.freebsd.org at Sat Feb 23 04:42:37 PST 2002
freebeast(5.0-C)[45]
So: how should this be resolved? Or am I just confused (again)?
Thanks,
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: Problem with buildworld: what is major really supposed to be?
Yeah, I'm chasing that one right now.
I'm not yet quite sure which commit has broken this, nor what the right
fix is...
Poul-Henning
In message [EMAIL PROTECTED], David Wolfskill w
rites:
Trying to make buildworld for today's -CURRENT, I get:
stage 4: building libraries
--
...
=== doc
cc -fpic -DPIC -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c
/usr/src/lib/libkvm/kvm_file.c -o kvm_file.So
In file included from /usr/obj/usr/src/i386/usr/include/sys/file.h:40,
from /usr/src/lib/libkvm/kvm_file.c:54:
/usr/obj/usr/src/i386/usr/include/sys/systm.h:305: syntax error before `int'
/usr/obj/usr/src/i386/usr/include/sys/systm.h:306: syntax error before `int'
/usr/obj/usr/src/i386/usr/include/sys/systm.h:307: syntax error before `('
*** Error code 1
After enough tinkering with copies of the files to demonstrate to
my satisfaction that my C skills are pretty rusty, I noticed that:
* The lines in systm.h look like (starting at line 301):
/*
* Common `dev_t' stuff are declared here to avoid #include poisoning
*/
int major(dev_t x);
int minor(dev_t x);
dev_t makedev(int x, int y);
udev_t dev2udev(dev_t x);
dev_t udev2dev(udev_t x, int b);
int uminor(udev_t dev);
int umajor(udev_t dev);
udev_t makeudev(int x, int y);
so it looks as if we're declaring major as a function returning int.
* But sys/sys/file.h, starting at line 49 reads:
#ifdef _KERNEL
#include sys/types.h
#include sys/queue.h
#include sys/_lock.h
#include sys/_mutex.h
which is OK, except that sys/sys/types.h, starting at line 113 reads:
/*
* minor() gives a cookie instead of an index since we don't want to
* change the meanings of bits 0-15 or waste time and space shifting
* bits 16-31 for devices that don't use them.
*/
#define major(x)((int)(((u_int)(x) 8)0xff)) /* major number */
#define minor(x)((int)((x)0x00ff)) /* minor number */
#define makedev(x,y)((dev_t)(((x) 8) | (y))) /* create dev_t */
and this appears to be a bit of a problem, because by the time the C
compiler gets to the int major(dev_t x); line in sys/sys/systm.h,
major has been replaced, so the line looks like:
int ((int)(((u_int)( dev_t x ) 8)0xff)) ;
which is pretty non-ideal, any way you look at it.
In case it's of interest/value, recent CVSup history is:
freebeast(5.0-C)[44] tail /var/log/cvsup-history.log
CVSup begin from cvsup14.freebsd.org at Tue Feb 19 03:47:02 PST 2002
CVSup ended from cvsup14.freebsd.org at Tue Feb 19 03:53:36 PST 2002
CVSup begin from cvsup14.freebsd.org at Wed Feb 20 03:47:02 PST 2002
CVSup ended from cvsup14.freebsd.org at Wed Feb 20 04:00:08 PST 2002
CVSup begin from cvsup14.freebsd.org at Thu Feb 21 03:47:03 PST 2002
CVSup ended from cvsup14.freebsd.org at Thu Feb 21 03:53:29 PST 2002
CVSup begin from cvsup14.freebsd.org at Fri Feb 22 03:47:02 PST 2002
CVSup ended from cvsup14.freebsd.org at Fri Feb 22 03:54:26 PST 2002
CVSup begin from cvsup14.freebsd.org at Sat Feb 23 04:35:13 PST 2002
CVSup ended from cvsup14.freebsd.org at Sat Feb 23 04:42:37 PST 2002
freebeast(5.0-C)[45]
So: how should this be resolved? Or am I just confused (again)?
Thanks,
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
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Problem with buildworld: what is major really supposed to be?
Ok, found it:
This is the culprit:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/file.h.diff?r1=1.39r2=1.40
In message [EMAIL PROTECTED], Poul-Henning Kamp writes:
Yeah, I'm chasing that one right now.
I'm not yet quite sure which commit has broken this, nor what the right
fix is...
Poul-Henning
In message [EMAIL PROTECTED], David Wolfskill w
rites:
Trying to make buildworld for today's -CURRENT, I get:
stage 4: building libraries
--
...
=== doc
cc -fpic -DPIC -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c
/usr/src/lib/libkvm/kvm_file.c -o kvm_file.So
In file included from /usr/obj/usr/src/i386/usr/include/sys/file.h:40,
from /usr/src/lib/libkvm/kvm_file.c:54:
/usr/obj/usr/src/i386/usr/include/sys/systm.h:305: syntax error before `int'
/usr/obj/usr/src/i386/usr/include/sys/systm.h:306: syntax error before `int'
/usr/obj/usr/src/i386/usr/include/sys/systm.h:307: syntax error before `('
*** Error code 1
After enough tinkering with copies of the files to demonstrate to
my satisfaction that my C skills are pretty rusty, I noticed that:
* The lines in systm.h look like (starting at line 301):
/*
* Common `dev_t' stuff are declared here to avoid #include poisoning
*/
int major(dev_t x);
int minor(dev_t x);
dev_t makedev(int x, int y);
udev_t dev2udev(dev_t x);
dev_t udev2dev(udev_t x, int b);
int uminor(udev_t dev);
int umajor(udev_t dev);
udev_t makeudev(int x, int y);
so it looks as if we're declaring major as a function returning int.
* But sys/sys/file.h, starting at line 49 reads:
#ifdef _KERNEL
#include sys/types.h
#include sys/queue.h
#include sys/_lock.h
#include sys/_mutex.h
which is OK, except that sys/sys/types.h, starting at line 113 reads:
/*
* minor() gives a cookie instead of an index since we don't want to
* change the meanings of bits 0-15 or waste time and space shifting
* bits 16-31 for devices that don't use them.
*/
#define major(x)((int)(((u_int)(x) 8)0xff)) /* major number */
#define minor(x)((int)((x)0x00ff)) /* minor number */
#define makedev(x,y)((dev_t)(((x) 8) | (y))) /* create dev_t */
and this appears to be a bit of a problem, because by the time the C
compiler gets to the int major(dev_t x); line in sys/sys/systm.h,
major has been replaced, so the line looks like:
int ((int)(((u_int)( dev_t x ) 8)0xff)) ;
which is pretty non-ideal, any way you look at it.
In case it's of interest/value, recent CVSup history is:
freebeast(5.0-C)[44] tail /var/log/cvsup-history.log
CVSup begin from cvsup14.freebsd.org at Tue Feb 19 03:47:02 PST 2002
CVSup ended from cvsup14.freebsd.org at Tue Feb 19 03:53:36 PST 2002
CVSup begin from cvsup14.freebsd.org at Wed Feb 20 03:47:02 PST 2002
CVSup ended from cvsup14.freebsd.org at Wed Feb 20 04:00:08 PST 2002
CVSup begin from cvsup14.freebsd.org at Thu Feb 21 03:47:03 PST 2002
CVSup ended from cvsup14.freebsd.org at Thu Feb 21 03:53:29 PST 2002
CVSup begin from cvsup14.freebsd.org at Fri Feb 22 03:47:02 PST 2002
CVSup ended from cvsup14.freebsd.org at Fri Feb 22 03:54:26 PST 2002
CVSup begin from cvsup14.freebsd.org at Sat Feb 23 04:35:13 PST 2002
CVSup ended from cvsup14.freebsd.org at Sat Feb 23 04:42:37 PST 2002
freebeast(5.0-C)[45]
So: how should this be resolved? Or am I just confused (again)?
Thanks,
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
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
