[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Installing WinAVR 20070122 broke older 3.4.5install?

From: Bruce D. Lightner
Subject: Re: [avr-gcc-list] Installing WinAVR 20070122 broke older 3.4.5install?
Date: Wed, 31 Jan 2007 15:00:11 -0800
User-agent: Thunderbird (Windows/20061207)

Eric Weddington wrote:
I agree that the situation can be improved w.r.t allowing multiple

Thanks, Bruce, for providing some concrete solutions.

The main problem that I've been dealing with since 2002 has been that the
GCC model is to build your compiler from source. GCC was not designed to be
relocated after it is built, as is the model with most Windows programs.

In the last few weeks, there was finally some help in the GCC project. A GCC
bug (that I opened) was finally fixed that makes GCC not look at the
configured prefix for relocated compilers.
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621> This was fixed for the
4.3 branch.

I haven't had time to test the official fixes, but I have other, older
patches, that are supposed to do the same thing. My intent is to see how
well the solution works and see if those patches can be backported for the
WinAVR distro.

So now it's time to revisit this whole issue and make it so WinAVR won't
have any problems in being relocated, as well as allowing multiple
installations, vis-a-vis registry settings, environment variables or
whatever. Registry settings seemed like the thing to do at the time, because
one can associate a distro with a distro-specific registry key such as:
..FSF\WinAVR_<version>\GCC etc.

My concern with doing enviornment variables is that AFAIK, it does not allow
different distros,.e.g. what if one has both an AVR GCC distro (WinAVR) and
an ARM GCC distro (WinARM)?

I'm open to suggestions that will work for all scenarios.

Thanks for a good discussion.
Eric Weddington


I'm glad you're open to making changes. I'm pretty sure you should be able to keep everyone happy, including the "naive" Windows users, with a registry-key scheme like the one you're using today.

Your last comment about using "environment variables" confuses me. I must be missing something, because I don't understand why "WinAVR" would conflict with "WinARM", unless you are thinking about a *globally* defined environment variable that needs to be shared by *both* cross-compilers, such as "GCC_ROOT" (see below).

I (and many others) may use environment variables under Windows in different way than you are used to. I almost never setup Windows environment variables and the PATH as "globals". (In the "good old days" this was done using "AUTOEXEC.BAT" when Windows was "booted".) That's what the Windows "registry" is for now days, and what you are doing today with the "registry" I think probably is fine, except for the fact that each WinAVR release does not use it's own set of unique registry entries.

That being said, if you can make use of the Windows "registry" *optional*, that's always better. I think "Windows install" programs with "secret" registry side-effects are "evil", but that's just me. Today, I can copy any of Microsoft's many versions of their command-line C compiler and linker anywhere I want, and as long as I setup the few needed environment variables and PATH (e.g., with a "command file") the software just works. No "install/uninstall" is required. Personally, I like that a lot!

Here's how I like to use "environment variables" under Windows: Instead of trying to make "environment variables (and the PATH) *global*, I use a ".PIF" or desktop "short-cut" which runs a .BAT (or .CMD) file to setup the "environment" for each particular "build" environment (i.e., when the new "command-prompt window" is opened). That BATCH/command file also is where I setup the PATH to include the WinAVR directory. That way one can have multiple versions of WinAVR running side-by-side. The key to making that work "naturally" is getting WinAVR to use environment variables to find stuff...if and only if they have been defined!

What Joerg says gives me hope that this can be made to work:

 Yes, they can be overridden with environment variables.  I had to
 review gcc/prefix.c again (I guess it's also in their docs, but the
 source code was easier to spot for me), the sequence is:

 .. when running in a Win32 environment, the registry key GCC is
   looked up,
 .. if not found, the environment variable GCC_ROOT is queried,
 .. if not found, the configure-time default prefix is used.

 So you have to remove the registry keys before the environment
 variables will get into effect.

That's useful information!

By "zapping" the Windows registry entries for WinAVR I can see how one could re-define $GCC_ROOT and get WinAVR to "behave" properly there needs to be multiple copies of WinAVR present. Unfortunately, deleting the registry entries can "break" other copies of WinAVR on a PC unless they also get the needed environment variable "tweak" for $GCC_ROOT. And, I see "danger" with this if "tweaking" the definition of $GCC_ROOT fouls up the *native* copy of "gcc"! I, for one, routinely compile "native" apps in the same command window where I'm developing and "cross-compiling" AVR code using "avr-gcc"! (But, maybe by using "Makefile magic" to reset $GCC_ROOT, this would not be a problem. It's just confusing to someone that does not know exactly what is going on!

If I had my way, I'd vote for one more "search" step, specific to WinAVR. Add one more step to the above "search list", namely a check for an environment variable such as "WINAVR_ROOT"...*first* in the list. This way, if and only if that "special" WinAVR environment variable is present then it overrides the (globally defined) registry-key information.

Another excellent option would be to use the "path" to the "avr-gcc" executable to find the other important "gcc" subdirectories, using "relative" paths off the "avr-gcc" executable's base path. In fact I *know* that this is the way "avr-gcc" *used to* work...at least for my old favorite "avr-gcc-2.95.2"! I wonder when that logic was removed? This allows you to move the "avr-gcc" release anywhere you want, as long as you keep everything "together". It is the *execution* of "avr-gcc" that sets the "search path".

How much trouble these various changes would be you will have to answer. I'm guessing that there is already WinAVR-specific code there anyway if the Windows registry is being used.

Best regards,


Bruce D. Lightner
Lightner Engineering
La Jolla, California
Voice: +1-858-551-4011
FAX: +1-858-551-0777
Email: address@hidden
URL: http://www.lightner.net/lightner/bruce/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]