[SM-Discuss] gcc parallel vs. /opt install
afrayedknot at thefrayedknot.armory.com
Fri Mar 10 12:42:43 EST 2006
On Fri, Mar 10, 2006 at 08:15:56PM +0800, sqweek wrote:
> 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
> For the multi version script you could probably get away with:
> /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.
Sorcery actually runs gcc from a wrapper script already. This is how
ccache and distcc get invoked. The script lives in /var/lib/sorcery/build.
| Andrew D. Stitt | acedit at armory.com | astitt at sourcemage.org |
| irc: afrayedknot | Sorcery Team Lead | ftp://t.armory.com/ |
| 1024D/D39B096C | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C |
More information about the SM-Discuss