Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] gcc parallel vs. /opt install

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: sqweek <sqweek AT gmail.com>
  • To: "SM Discuss" <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] gcc parallel vs. /opt install
  • Date: Fri, 10 Mar 2006 20:15:56 +0800

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.




Archive powered by MHonArc 2.6.24.

Top of Page