[don't mail me, I'm going on holiday Real Soon Now again]
Am I the only one getting duplicated #include lines in the generated
ioctl.c file, created as part of building usr.bin/kdump?
Probably yes, because when I build things in other locations (I'm
using a MAKEOBJDIRPREFIX), I don't see the lines in those ioctl.c
files...
I'm using the relevant make.conf lines to set MAKEOBJDIRPREFIX as
RELNAME!= /usr/bin/uname -r
MAKEOBJDIRPREFIX?= /usr/local/obj/${RELNAME}
This puts everything in paths like this...
bash-2.05a$ less -N /usr/local/obj/5.0-CURRENT/usr/src/usr.bin/kdump/ioctl.c-BUGGY
[...]
23 #include <cam/cam.h>
24
25 const char *ioctlname(u_long val);
26
27 #include <cam/scsi/scsi_pass.h>
28 #include <cam/scsi/scsi_ses.h>
29 #include <cam/scsi/scsi_targetio.h>
30 #include <cam/scsi/scsi_pass.h>
31 #include <cam/scsi/scsi_ses.h>
32 #include <cam/scsi/scsi_targetio.h>
33 #include <dev/ppbus/lptio.h>
34 #include <dev/ppbus/ppi.h>
35 #include <dev/usb/dsbr100io.h>
Note that lines 27-29 match lines 30-32, leading to a build failure
like
cc -O -pipe -DMAXPARTITIONS=16 -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/us
r.bin/kdump/../.. -c ioctl.c
In file included from ioctl.c:31:
/usr/local/obj/5.0-CURRENT/usr/src/i386/usr/include/cam/scsi/scsi_ses.h:88: conf
licting types for `ses_object'
/usr/local/obj/5.0-CURRENT/usr/src/i386/usr/include/cam/scsi/scsi_ses.h:88: prev
ious declaration of `ses_object'
/usr/local/obj/5.0-CURRENT/usr/src/i386/usr/include/cam/scsi/scsi_ses.h:128: con
flicting types for `ses_objstat'
/usr/local/obj/5.0-CURRENT/usr/src/i386/usr/include/cam/scsi/scsi_ses.h:128: pre
vious declaration of `ses_objstat'
[snip]
If I `make' with `env MAKEOBJDIRPREFIX=...' in the source directory
/usr/src/usr.bin/kdump/ itself, it builds (more or less) fine...
25 const char *ioctlname(u_long val);
26
27 #include <cam/scsi/scsi_pass.h>
28 #include <cam/scsi/scsi_ses.h>
29 #include <cam/scsi/scsi_targetio.h>
30 #include <dev/ppbus/lptio.h>
31 #include <dev/ppbus/ppi.h>
[...]
However, there seem to be significant differences between the two
generated ioctl.c files (including another duplicated disklabel.h line).
(Also, I had done a `make includes' for laughs, and I seem to have
needed to hack the new /usr/include/sys/proc.h to be like
u_char ar_args[0]; /* Arguments. */
as was my old proc.h from March, in order to get the kdump binary
to be built by hand after the `make includes')
Is this b0rken for me because I'm using a make.conf MAKEOBJDIRPREFIX,
and I now have to give it on the command line? Oh, just for laughs,
I did a buildworld, specifying `env MAKEOBJDIRPREFIX' on the make line,
with the same results as earlier (failed build, as the .depends file
is regenerated, so a new ioctl.c file is generated even if I have a
successful kdump binary, meaning it gets rebuilt)... Or might the
fact that I'm using a unionfs mount over /usr/src have something to
do with it (since disklabel.h appears twice with `ls' since I needed
to hack it in the upper unionfs layer)... Source is current of last
night, while the -current I'm trying to update from was built early
march (cough)
Just to be *really* sure, I've commented out my make.conf lines, and
am doing another -DNOCLEAN buildworld, and I guess if that fails too,
when I get back, I'll do it again without the -DNOCLEAN (started with an
empty MAKEOBJDIRPREFIX just for safety), to see if I can get things
working for me... (Nope, failed too, have to try again later, sigh)
(sorry if I'm being typically unclear)
thanks
barry bouwsma
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
