[SM-Discuss] gcc parallel vs. /opt install

sqweek sqweek at gmail.com
Fri Mar 10 07:15:56 EST 2006


On 08/03/06, David Brown <dmlb2000 at gmail.com> wrote:
> 2) Complicated projects make it harder
> For larger packages I found it didn't work so well, no matter what I
> did to the monolithic xorg 6.8.2 it would still end up using gcc
> instead of gcc-3.4 and I never figured out how to make it work.  Also
> larger autotooled packages required lots of var setting, CC CXX CPP
> are just a few.

 I've had a bit of experience in this area at work, where I've had to
deal with... "difficult" build systems, while cross-compiling (my
machine is 64-bit but the stuff needs to run on the 32-bit laptops we
have around).
 Anyway, I think I worked out a pretty reliable way to give any build
system the finger and compile using the flags *I* want, which is to
have gcc as a wrapper script. I have it in ~/bin/gcc, but to work with
autotools the script probably has to be the main /usr/bin/gcc.

 The idea is simple: in normal circumstances the script just passes
its arguments directly through to gcc. But, if a special environment
variable is set (in my case XCOMPILE), it adds a couple of options (eg
-m32).

 For the multi version script you could probably get away with:
#!/bin/sh
/usr/bin/gcc$SORCERY_GCC_VERSION "$@"

 But I can see a couple of potential problems/hassles:
1) hardcoded /usr/bin path in wrapper script
2) unconventional hack (afaik?) - its not something that's going to be
obviously guessable if it causes problems
3) one extra difference between sorcery's environment and the standard
4) you need a script for gcc, g++, g77, cc, c++ (ok symlinks) - ie
every compiler you want to support multiple versions for

 I think 2) is the biggest criticism - I can see countless sysadmins
coming across the wrapper script and just going "wtf that's retarded".
But even if it's not system-wide, perhaps this approach could be
useful for the more complicated builds.



More information about the SM-Discuss mailing list