avr-gcc-list
[Top][All Lists]
Advanced

[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: Joerg Wunsch
Subject: Re: [avr-gcc-list] Installing WinAVR 20070122 broke older 3.4.5install?
Date: Thu, 1 Feb 2007 00:54:02 +0100 (MET)

"Bruce D. Lightner" <address@hidden> wrote:

> 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 think a global environment variable would be Eric's only alternative
to a registry key, when considering what the WinAVR installer could do
at installation time.

It's a bit counterintuitive that GCC prefers the Windows registry key
over an environment variable.  In Unix, environment variables have
usually been used to override defaults, but that would no longer be
possible once the registry key in place.  If you don't like that,
please file a bug report with the GCC (and binutils) folks.  I don't
know what's the reasoning for this.

The only simple solution I could think of Eric might implement is to
ask the user/administrator at installation time, whether the registry
keys should be brought into place, or whether the user would rather
like to handle that on their own, using environment variables.

I agree though, system-wide environment variables are completely
unsuited as the name of the variable being looked up is always one of
GCC_ROOT, BINUTILS_ROOT, etc -- independent of whether this is a
cross-compiler or not.

> If I had my way, I'd vote for one more "search" step, specific to
> WinAVR.

Alas, that'll require Eric to patch all the tools specifically for
each and any WinAVR release, as there's certainly no chance to get a
hack like that into the regular GNU tools.

> 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.

I think that's the (now fixed) bug Eric has been referring to.

This is not the Unix way of doing things so, in particular, argv[0] on
Unix usually not contains a full path name, nor is it even
*guaranteed* a path name to the executable really exists by the time
it is being executed.  (In Unix, you can delete a file from the file
system while it is still being executed.  It will be physically
deleted only after finishing, but no path name in the file system does
exist then pointing to it.)

> I'm guessing that there is already WinAVR-specific code there anyway
> if the Windows registry is being used.

No, up to that, all that Eric had to do was to run the configure step
with --enable-win32-registry=WinAVR.  No further code changes needed,
everything else is already in place in binutils and GCC.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)




reply via email to

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