Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Jun 2002 16:09:54 +0200 (CEST)
From:      BOUWSMA Beery <freebsd-misuser@ipv6.netscum.dyndns.dk>
To:        freebsd-current@freebsd.org
Subject:   duplicate includes in kdump/ioctl.c ?
Message-ID:  <200206271409.g5RE9sYk065255@netscum.dyndns.dk>

next in thread | raw e-mail | index | archive | help
[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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206271409.g5RE9sYk065255>