Some time ago we discussed a desire to post at our wiki package-specific information needed for building.
Recently Tim and I ran into an interesting quirk with building on 64-bit. (Thanks Tim!) I decided this information should be in the wiki. If you're curious, the quirk is that for 64-bit, building (T)Qt3 with the following configure option might be needed:
-platform ${PLATFORM}
Where, for 64-bit, ${PLATFORM} == linux-g++-64 rather than linux-g++.
Recent posts by Nix regarding build issues also remind me of this wiki need.
Perhaps the time has arrived that we start accumulating this information for the wiki.
For now, perhaps we share information here in the mail list, which will serve somewhat as a way for providing peer reviews before posting to the wiki.
I'm thinking eventually we have a page for each package, even thos that are quite generic with build configurations. Each wiki page will list no less than minimum build information. For many packages they all will look the same except for the package name. Just cookie-cut information because there is nothing complicated about those packages.
We then move many of our preliminary wiki notes to those package-specific pages.
Currently section 5 of the wiki page is our potential portal to individual package information. We can create links in that section as we create each new wiki page for each package.
All I'm asking for at this point is we start pooling knowledge.
We have a project goal of releasing R14 when ready but are focusing on summer's end. That provides us ample time to assemble this information.
Please help!
Darrell
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.
-
Darrell Anderson -
Nix