[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

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>
      25 const char *ioctlname(u_long val);
      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
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'

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

barry bouwsma

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

Reply via email to