Re: Update: crossbuilding under older 4.x FreeBSD

[Barry Bouwsma <freebsd-misuser@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

[don't reply to me yet -- keep replies on the list for now]

Concerning my problems with a few includes files showing up in
my source tree, with my hacks:

>     This can't be it.  The osreldate.h-in-the-source-tree issue
>     usually means that a build was done without the proper
>     object environment being created.  Stale files in the 
>     source tree can cause the buildworld to get confused.  If we
>     are actually missing part of the object hierarchy here we
>     need to fix that rather then hack around the modules where
>     the error occurs.

Just to be sure that we aren't talking past one another --
The actual `includes' crossbuild succeeds.  The part that fails
for me is that the build needs a few includes files that aren't
present in my older FreeBSD.  As a hack workaround for this,
I do a quick and probably wrong `installincludes' into a directory,
which then I preferentially include when doing the rest of the
crossbuild.  This is the first step of my hacked crossbuild.

It's my hack that causes the problem -- not DFly's build.  All
files, except for osreldate.h, version/.c, and the few in the
rpc/rpcsrv subdirs I noted, get populated into the specified target.

Actually, after a week-old-ish message from Ruslan in the FreeBSD
mailing list, I've just posted to ask about this.  The osreldate.h
file that is created by my `installincludes' step is going to cause
problems for me, correct? -- because it's that of my DFly source,
while the one that should be used during the build to identify the
system (FreeBSD as crossbuild host) would not be seen if that appears
in the preferred path, similar to the `make includes' step in the
FreeBSD-current mail that prompted my query?  (I think this question
doesn't make sense)

My `crossincludes' target tries to be as simple as possible, so
one only gets the missing includes or up-to-date ones, rather than
a comprehensive target.  If I look at a random FreeBSD build's
obj directory, I see the following, rather than everything that
gets put into /usr/include:

ls /stand/obj/FreeBSD6/stand/FreeBSD-CURRENT-src/src/include/
osreldate.h     rpc             rpcsvc          vers.c          version

These are the problematic files for my `crossincludes' hack.
So you are correct that by not creating an obj tree before this
step in the build, they have nowhere to go but the source.

So far, rpc/* and rpcsvc/* remain compatible from my old FBSD
to the lastest 'Fly, and I think I *don't* want to refer to
osreldate.h, vers.c, or version during the build, based on
their contents, when I should refer instead as needed to the
FBSD /usr/include/osreldate.h (haven't found the others in my
host system yet).



>     Try a completely fresh source tree checked out from cvs and
>     run a from-scratch buildworld (without -j either), and if it
>     still fails put the output somewhere where I can fetch it (don't
>     post it, it's going to be too big).

My build steps are:
`cvsup' latest source from local CVS repository
   -- I need to run `cvsupchk' (again?) to verify this source is
      clean, but it should be.
unionfs-mount a small number of local hacks atop this source.  If
 anything tries to be written in the source directory, it will then
 show up in this unionfs source-hacks filesystem, and can easily be
 found by the `find' I run to verify my hacks remain up-to-date.
move my last build out of the way to start clean
do the build, which creates a fresh /stand/obj/DragonFly/...


Anyway, I'm learning a lot about this process from both this
crossbuild attempt and from what I'm learning from Ruslan and
experiencing under FreeBSD crossbuilds, so I value all the
info I'm getting.  Much appreciated.


So, um, my real question would be, is it reasonable for me to
want to create a DFly-specific `includes' directory at the start
of my crossbuild so that I can get the latest headers to work
around the failures I had initially observed, while excluding
the particular headers that are needed during the build (I'll
let Ruslan educate me on which those are, I hope)?


thanks
barry bouwsma