Jason Thorpe <thorpej@nas.nasa.gov> writes:


> > OBJ_ARCH will be available through "sysctl -n hw.obj_arch" very similarly to
> > "sysctl -n hw.machine_arch".  It would probably be useful to make a uname
> > option for it as well, i.e. "uname -o", just for user simplicity.

>That's completely nuts!

>Say I have a NetBSD/i386 system.  I CAN BUILD i386 ELF BINARIES AND RUN THEM,
>TODAY!  So, what does my OBJ_ARCH say on a system today?  Note our "native"
>format is a.out!

Todd's original proposal was to explicitly tie ${MACHINE_ARCH} to a
specific GNU binutils backend vector (default toolchain output).  I
think that's going too far, irrespective of whether it's
${MACHINE_ARCH} or ${OBJ_ARCH} which gets fragmented.

That's why I objected to it. I'm glad you agree with that much.

I still think there are two conceptually different things being
described here, which were never considered until we started
supporting multiple endian-nesses on a given CPU, or (soon) multiple
pointer-size models on a given CPU.

For those, I think we need clearly do need two levels of naming: one
for the coarse-grained ``architecture family'' , and one for the
fine-grained.

Think about what happens when we support 64-bit sparc binaries.  Does
that mean sparc64 becomes a new machine_arch? Todd and Eduardo seem to
think so.  Does that mean we need separate arch/{sparc,sparc64}
directories everywhere?  Does it mean CPP no longer predefines
__sparc__ on a sparc64?  What does that mean for package source that
wants to compile sparc-specific C source that works in LP32 or LP64
but just wants to test for "sparc"?   What  does the vendor environment do?




What i see here is many questions that were all the same when a
${MACHINE_ARCH} meant an entire CPU family, and nobody thinking
through what happens when we change that.

I think one thing that happens is that source-level and binary-level
definitions of ${MACHINE_ARCH} really arne't the same.  We pride
ourselves on doing things ``right''.  Fragmenting ${MACHINE_ARCH}
without thinkinga bout it is clearly not ``right''.