Bad Commit!!!!!!

The most recent CLFS commit (r3153 - in
/trunk/BOOK/final-system/multilib: procps-64bit.xml procps-n32.xml
procps.xml) is wrong.

I know that this is somewhat hard to believe, but m64="${BUILD32}" and
m64="${BUILD64}" were RIGHT.  Take a look at the Makefile and you'll
see for yourself.  According to the various comments in the Makefile,
the package maintainer thinks that /lib64 and /usr/lib64 and the like
are an "abomination" (his word).  I don't know if that's why he did
what he did, but he made the Makefile VERY abnormal.  Here's one
portion of it:


# Be 64-bit if at all possible. In a cross-compiling situation, one may
# do "make m64=-m32 lib64=lib" to produce 32-bit executables. DO NOT
# attempt to use a 32-bit executable on a 64-bit kernel. Packagers MUST
# produce separate executables for ppc and ppc64, s390 and s390x,
# i386 and x86-64, mips and mips64, sparc and sparc64, and so on.
# Failure to do so will cause data corruption.
m64 := $(call check_gcc,-m64,$(call check_gcc,-mabi=64,))
ALL_CFLAGS += $(m64)



If you follow the CC="gcc ${BUILD32}" route, you'll get both -m32 and
-m64 (with the -m64 second, thus overriding the -m32).  You'll also
have it using /usr/lib64 and /lib64.

I totally understand why Jim thought that it was an error, but the
commit needs to be undone - or have a new commit committed to fix it
or whatever.  Perhaps a note on the sheer screwy-ness of the Makefile
would be in order as well so that this mistake doesn't happen again.
If nothing else, there are bound to be CLFS users that assume that it
must be a mistake and thus do what the new commit says.

- Jonathan Davis