uVision3 and GNU chain problem

"0 Error(s), 0 Warning(s)."

That means it worked!
What's your problem? - the file has been successfully translated!!

If you want to build a complete executable image, rather than just translate a single source file, you will have to press one of the Build buttons!

The error message suggests something went wrong with the construction of a command line for GCC. It's essentially impossible to be any more specific if you don't show that command line (and give a rough description of what you did to get there).

hey guys...it was quite simple. KEIL apparently hates long file names. i initially installed KEIL into C:\Program Files\KEIL...which was the problem. i reinstalled to C:\KEIL which works fine now.

yes there were no errors, but i still couldnt build anything. i rebuilt all the files and it wouldnt create the target. i'd get the following after i tried to build:

Build target 'Target 1'
compiling pot.c...
arm-uclibc-gcc: cannot specify -o with -c or -S and multiple compilations
assembling startup.s...
Assembler messages:
Error: Error: can't open Files\KEIL\ARM\INC\ADI\ for reading
Files\KEIL\ARM\INC\ADI\: No error
Target not created

thanks for the help though!

KEIL apparently hates long file names.

No. I don't think so. Since I have never received this error I can only assume that there's something different about your setup.

Where did you install cygnus and did you use the one from the Keil web site?

Jon

"KEIL apparently hates long file names. i initially installed KEIL into C:\Program Files\KEIL...which was the problem"

Actually, I doubt that it has anything to do with Keil.
It's probably not even long filenames, but the use of spaces in file and/or folder names!

Remember, GNU is of UNIX origin; UNIX doesn't mind long filenames, but doesn't do spaces in filenames!

Remember, GNU is of UNIX origin; UNIX doesn't mind long filenames, but doesn't do spaces in filenames!

GNU tools, like most Unix tools of these days, can deal with spaces in filenames quite fine --- if you pass them in correctly, so blanks inside arguments can be distinguished from blanks separating arguments. The onus is on uVision, here: it should have either quoted this -I argument, or generated a message at installation time that blanks in filenames had better be avoided.

This is not a Unix particularity at all, but rather a general feature of all command-line tools facing blanks in filenames. The problem is actually a lot more common on Windows than on Unix. Unix people usually know enough about command line usage to avoid putting blanks in the middle of a filename.

Microsoft, OTOH, decided to force this misery on everybody, by using as many long filenames with as many spaces in them, in a default installation, as they could get away with. Thus "Program Files" instead of "Programs", and "Documents and Settings" instead of "Home" or "Users"

"Microsoft, OTOH, decided to force this misery on everybody, by using as many long filenames with as many spaces in them, in a default installation, as they could get away with. Thus 'Program Files'..."

Absolutely - complete idiocy!

Microsoft, OTOH, decided to force this misery on everybody

Not really force, they "strongly suggest".

I have my development tools (including Keil) in subdirectories under c:\tools\

In all reasonableness (argh, could not find a better word) Windows was never intended for what we use it for. That I am on the "spray the Gatesians with tar and feathers" team after they made it impossible to run "true" DOS is another matter.

Erik

Not really force, they "strongly suggest".

Well --- you try to sell a mainstream application without the current "Designed for Windows..." logo on it, or try to get that logo for a program that doesn't install under "c:\program files" (or it's i18n'd equivalent) by default. I think it'll feel rather much like being forced, as in: you either do as we say, or you'll be out of business.

Well --- you try to sell a mainstream application without the current "Designed for Windows..." logo on it, or try to get that logo for a program that doesn't install under "c:\program files" (or it's i18n'd equivalent) by default

I have not installed any programs that did not allow me to change the installation subdirectory.
If you muddle along and accept all defaults, then you only have yourself to blame. The defaults are for the 99% of windows customers that have no problem with "Gates Rule".
I, however, do not believe that Bill Gates know better than me what I want.

Erik

GNU tools, like most Unix tools of these days, can deal with spaces in filenames quite fine --- if you pass them in correctly, so blanks inside arguments can be distinguished from blanks separating arguments. The onus is on uVision, here: it should have either quoted this -I argument, or generated a message at installation time that blanks in filenames had better be avoided.

OK. So, I installed the Keil tools as the previous poster described (under the Program Tools folder) and I compiled each and every GNU example program we provide. They each compiled with no errors and no warnings. There were many spaces in the path to the tools and in the path to the examples.

Then I started looking for a POT.C file. I couldn't find one. So, I think a little more information is required to solve this issue.

1. Where did the POT.C file come from?

2. Is it part of the Analog Device's CD-ROM or was it obtained from a Keil CD?

3. What version of uVision3 are you using (click help-about)?

The answers to these questions will help to resolve this issue.

Jon

OK. So, I installed the Keil tools as the previous poster described (under the Program Tools folder) and I compiled each and every GNU example program we provide. They each compiled with no errors and no warnings. There were many spaces in the path to the tools and in the path to the examples.

Then I started looking for a POT.C file. I couldn't find one. So, I think a little more information is required to solve this issue.



1. POT.C came from KEIL code examples that was included in my ADuC7026 eval board.
C:\ADuC_Beta702x\Code\Keil Code Examples\ADC\Pot.c

2. I initially installed uV3 from a KEIL CD. But I also encountered the same problem from the Analog Device CD-ROM as well.

3. I used two versions. the Analog Device KEIL had a release 7.2004 (V3.05b), and the KEIL CD had a release 10.2004(do i really have to reinstall?). Both versions encountered the same problem until I moved the KEIL directory from C:\Program Files\KEIL... to C:\KEIL...