On 14 Jun 2012, Darrell Anderson said:
> -platform ${PLATFORM}
>
> Where, for 64-bit, ${PLATFORM} == linux-g++-64 rather than linux-g++.

This can alternatively be worked around by making the compiler respond
to the 64-bitness state. You could do this by replacing one's g++ and
c++ with a suitable shell script, and moving g++ out of the way -- I
move /usr/bin/gcc to /usr/bin/.wrapped/gcc and likewise for g++, c++ et
al -- or by putting the wrapper in another directory and pointing PATH
at it.

I use this script, which seems to work:

#!/bin/bash
#
# Default to -m64 unless in 32-bit mode or -m32 is specified.
#

if [[ "$@" =~ (^| )-m(32|64)( |$) ]]; then
    exec ${0%/*}/.wrapped/${0##*/} "$@"
elif [[ "$(uname -m 2>/dev/null)" =~ 64 ]]; then
    exec ${0%/*}/.wrapped/${0##*/} -m64 "$@"
else
    exec ${0%/*}/.wrapped/${0##*/} -m32 "$@"
fi

This has some minor negative performance implications for compilation
times though. (Using dash would work if dash supported =~, which it
doesn't, so you have to run expr twice, which is much slower than
starting bash.)


Closer to ideal would be making the compiler capable of switching
default depending on utsname value, so it would be automatically
responsive to e.g. 'linux32' or 'linux64' with no horrible hacky shell
script required. (I have promised someone at work that I'll implement
this, and will contribute it upstream after that.)

(There are other things you have to do for a reliable biarch
configuration, such as putting 32-bit include files in a different
place, e.g. /usr/include/32, and pointing the include path for 32-bit
builds through that directory. Multiarch, as in recent Debian, is even
more... amusing to make work.)

> Recent posts by Nix regarding build issues

I still can't build kdeaccessibility (or, probably, any Trinity packages
relying on autoconf and uic together) :(

> All I'm asking for at this point is we start pooling knowledge.

Excellent idea.

-- 
NULL && (void)