Hello, I'm trying to evaluate the YAGARTO package. The compiler is responding normally to the command C:\>arm-elf-gcc --version, but I got an error message when trying to compile a simple main.c file (arm-elf-gcc main.c). The message is: "arm-elf-gcc: _spawnv: no such file or directory" I don't know how to solve it. Is there anybody that could help? Thanks in advance! Dimitar
Dimitar Alexandro wrote: > Hello, > > I'm trying to evaluate the YAGARTO package. The compiler is responding > normally to the command C:\>arm-elf-gcc --version, but I got an error > message when trying to compile a simple main.c file (arm-elf-gcc > main.c). > The message is: "arm-elf-gcc: _spawnv: no such file or directory" > I don't know how to solve it. > Is there anybody that could help? > > Thanks in advance! > > Dimitar Such a problem is well known with OLDER versions of WinARM in combination with Windows98SE as host machine. See bugreport at http://en.mikrocontroller.net/topic/62432 And fix from Martin Thomas http://en.mikrocontroller.net/topic/67766 Maybe you are in the very same situation with YAGARTO? Stefan
Stefan wrote: > Dimitar Alexandro wrote: >> Hello, >> >> I'm trying to evaluate the YAGARTO package. The compiler is responding >> normally to the command C:\>arm-elf-gcc --version, but I got an error >> message when trying to compile a simple main.c file (arm-elf-gcc >> main.c). >> The message is: "arm-elf-gcc: _spawnv: no such file or directory" >> I don't know how to solve it. >> Is there anybody that could help? >> >> Thanks in advance! >> >> Dimitar > > Such a problem is well known with OLDER versions of WinARM in > combination with Windows98SE as host machine. > > See bugreport at > http://en.mikrocontroller.net/topic/62432 > > And fix from Martin Thomas > http://en.mikrocontroller.net/topic/67766 > > Maybe you are in the very same situation with YAGARTO? > > Stefan Thank You Stefan, but I still don't find the solution. Before posting here I've searched the forum for a similar bug repots as mine one, but I was suprised that the bug is reported only for WIN98SE. Sorry, but I forgot to tell you that I'm using WIN XP PRO + SP2 :( I also got the same error message on WIN XP PRO SP1. This really freaks me, how come this happens only to me??? I haven't tried yet with the compiler in the WINARM collection, only with the latest package from YAGARTO. Dimitar
Fordp wrote:
> Check your path.
I've done it, it sems to be OK, here it is:
<em>
C:\Program Files\Atmel\WinAVR\bin;
C:\Program Files\Atmel\WinAVR\utils\bin;
C:\PROGRA~1\Borland\CBUILD~1\Projects\Bpl;
C:\PROGRA~1\Borland\CBUILD~1\Bin;
%SystemRoot%\system32;
%SystemRoot%;
%SystemRoot%\System32\Wbem;
C:\PROGRA~1\Tcl\bin;
c:\ed\cadtools\mlxbin;
%XILINX%\bin\nt;
C:\Program Files\Altium2004 SP2\System;
C:\PROGRA~1\CA\SHARED~1\SCANEN~1;
C:\PROGRA~1\CA\ETRUST~1;
"C:\Program Files\Symantec\Norton Ghost 2003\";
C:\Program Files\openocd-2006re100\bin;
C:\Program Files\openocd-2006re100\utils\bin;
C:\Program Files\yagarto\bin
</em>
Do you see something not OK or missing?
I use a clean path variable on my system with autoexec.bat and a selection of the one and only toolchain i want to work with (there are 10 to select from now ;-). You can also try to put the definitions needed for arm gnu toolchain in the path on the first place. Paths with blank might give trouble in the toolchain when not quoted. Check the command lines and batchfiles whether commands are quoted e.g. "c:\program files\...". Or move the toolchain to a path without blanks. And just a hint: "C:\>arm-elf-gcc..." - i wouldn't really like to compile in the root directory of the system partition ;-) Stefan
Hello Dimitar,
I have checked it here, and installed the toolchain under
c:\Program Files. I have no problem, and I use WIN XP PRO + SP2 too.
This was my main.c:
int main (void)
{
return(0);
}
How does your main.c looks like?
Regards,
Michael
Michael Fischer wrote: > Hello Dimitar, > > I have checked it here, and installed the toolchain under > c:\Program Files. I have no problem, and I use WIN XP PRO + SP2 too. > > This was my main.c: > > int main (void) > { > return(0); > } > > > How does your main.c looks like? > > Regards, > > Michael Hello Michael, I'm strictly following the instructions of your HOW TO page - http://www.yagarto.de/howto/yagarto1/index.html Thus my main.c programme is the same as yours. I'm going to try the WINARM compilation, as there is the same compiler inside (GCC-4.1.1) Thanks for the suggestion, Dimitar
Stefan wrote: > I use a clean path variable on my system with autoexec.bat and a > selection of the one and only toolchain i want to work with (there are > 10 to select from now ;-). You can also try to put the definitions > needed for arm gnu toolchain in the path on the first place. Stefan, thanks for the hints, but still nothing. I've tried with a clean PATH variable (SET PATH C:\Program Files\openocd-2006re100\bin; C:\Program Files\openocd-2006re100\utils\bin; C:\Program Files\yagarto\bin) but it didn't worked. > Paths with blank might give trouble in the toolchain when not quoted. > Check the command lines and batchfiles whether commands are quoted e.g. > "c:\program files\...". Or move the toolchain to a path without blanks. > > And just a hint: > > "C:\>arm-elf-gcc..." - i wouldn't really like to compile in the root > directory of the system partition ;-) I also don't like it, but the location is not the problem. I thin there is nothing wrong with the PATH, since the compiler responds correctly to the arm-elf-gcc --version, it could be invoked from anywhere. Dimitar > > Stefan
A working command arm-elf-gcc --version says nothing (almost). The compiler driver gcc has to invoke other programs such as the preprocessor and the assembler. This works through the _spawnv function. You can check file search paths with the free FILEMON tool from www.sysinternals.com Try SET PATH "C:\Program Files\openocd-2006re100\bin";"C:\Program Files\openocd-2006re100\utils\bin";"C:\Program Files\yagarto\bin" I would also try to copy yagarto to c:\yagarto and use this path SET PATH C:\yagarto\bin;"C:\Program Files\openocd-2006re100\bin";"C:\Program Files\openocd-2006re100\utils\bin" Stefan
Stefan wrote: > A working command arm-elf-gcc --version says nothing (almost). > > The compiler driver gcc has to invoke other programs such as the > preprocessor and the assembler. This works through the _spawnv function. > > You can check file search paths with the free FILEMON tool from > www.sysinternals.com > > Try SET PATH "C:\Program Files\openocd-2006re100\bin";"C:\Program > Files\openocd-2006re100\utils\bin";"C:\Program Files\yagarto\bin" > > I would also try to copy yagarto to c:\yagarto and use this path > SET PATH C:\yagarto\bin;"C:\Program > Files\openocd-2006re100\bin";"C:\Program > Files\openocd-2006re100\utils\bin" > > Stefan Stefan, thanks once again for your comments. I've tried your both suggestions, still don't work :_( When I tried to use the compiler from the WINARM collection (SET PATH=C:\Program Files\Atmel\WinARM\bin;C:\Program Files\Atmel\WinARM\utils\bin) I didn't got the annoying message (arm-elf-gcc: _spawnv: no such file...), but the foloowing errors: C:\Temp>arm-elf-gcc main.c c:/program files/atmel/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/l ib\libc.a(exit.o): In function `exit': exit.c:(.text+0x28): undefined reference to `_exit' c:/program files/atmel/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/l ib\libc.a(mallocr.o): In function `_malloc_r': mallocr.c:(.text+0x424): undefined reference to `_sbrk_r' mallocr.c:(.text+0x4cc): undefined reference to `_sbrk_r' c:/program files/atmel/winarm/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/l ib\libc.a(freer.o): In function `_malloc_trim_r': mallocr.c:(.text+0x48): undefined reference to `_sbrk_r' mallocr.c:(.text+0x64): undefined reference to `_sbrk_r' mallocr.c:(.text+0x84): undefined reference to `_sbrk_r' collect2: ld returned 1 exit status The main.c programme is as follows: int main (void) { return(0); } I'm going into deep sh*t. I expected a problem with the linker, not with the compiler....:_( I'll appreciate any tips concerning the WINARM. Dimitar
Hello Dimitar, your last errors are good errors :-) The WinARM collection comes without the syscalls, you must replace it by yourself. The examples from WinARM has a file called syscalls.c, here you could find the funtions like: _sbrk_t, exit and so on. Take a look at the examples. Best regards, Michael
Michael Fischer wrote: > Hello Dimitar, > > your last errors are good errors :-) > > The WinARM collection comes without the syscalls, > you must replace it by yourself. The examples from WinARM > has a file called syscalls.c, here you could find the > funtions like: _sbrk_t, exit and so on. > > Take a look at the examples. > > Best regards, > > Michael Michael, thanks for the good news and for the info. Indeed I didn't checked the examples yet. I hope that finally I'm on the right track. Best regards, Dimitar
Michael Fischer wrote: > Hello Dimitar, > > your last errors are good errors :-) > > The WinARM collection comes without the syscalls, > you must replace it by yourself. The examples from WinARM > has a file called syscalls.c, here you could find the > funtions like: _sbrk_t, exit and so on. > > Take a look at the examples. > > Best regards, > > Michael Hello Michael perhaps you can change the gcc source the same way Martin Thomas did in order to fix the _spawnv/_spawnvp problem. I get the very same error with Yagarto on Win98SE which i got with older versions of WinARM too. Matin patched the source with a change from the gcc CVS source tree and the error was gone... Another "problem" - during installation of Yagarto on Win98SE the PATH in autoexec.bat was not updated. Perhaps some hints in the doc what PATH is required is useful too. Bye Stefan
Hello Stefan, > perhaps you can change the gcc source the same way Martin Thomas did in > order to fix the _spawnv/_spawnvp problem. I get the very same error > with Yagarto on Win98SE which i got with older versions of WinARM too. > Matin patched the source with a change from the gcc CVS source tree and > the error was gone... I do not know which patch I must use. I have NO Win98SE here, only XP. Therefore I could not test if the patch is working. @Martin Which patch you have used to solve this problem? Actually I would like to wait for the official release which has fix the problem. The other problem will be OpenOCD. I belive that OpenOCD is not working under Win98, or is it? > Another "problem" - during installation of Yagarto on Win98SE the PATH > in autoexec.bat was not updated. Perhaps some hints in the doc what PATH > is required is useful too. Yes this is correct, I do not set any PATH in the autoexec.bat. I use some registry entries to set the path under XP. The GCC was created with: --enable-win32-registry=yagarto Therefore you must set some keys in the registry too. I do not know if this is working under Win98 too? HKLM\SOFTWARE\Free Software Foundation\yagarto Here the path for BINUTILS, G++ and GCC is set. I will add a not on the page. Best regards, Michael
As far as i understand, the problem is, that the bug and the fix is well known long time ago but it didn't make it into gcc 4.x. I do volunteer for testing on Windows98SE. OpenOCD... I have no problems with OpenOCD-pp R100 from Yagartos download site and gdb/insight from GNUARM toolchain on Windows98SE. There is a error message that giveio.sys can not be installed but this is no problem when debugging. The registry entries... i'll check this with REGMON, but i think my shell programs (4DOS or bash/Cygwin) don't check these entries. I use a similar entry like in the WinARM or GNUARM toolchains (PATH=...\Yagarto\bin;%PATH%) now and arm-elf-gcc is starting, but i can't check the whole toolchain because of the _spawnv/_spawnvp problem. Stefan
Stefan wrote: > As far as i understand, the problem is, that the bug and the fix is well > known long time ago but it didn't make it into gcc 4.x. I do volunteer > for testing on Windows98SE. Maybe you can understand Martin's changes from this reply: http://en.mikrocontroller.net/topic/67766
Hello Stefan, can you contact me off-list? You will find my email address at the imprint. Regards, Michael
Michael Fischer wrote: > @Martin > Which patch you have used to solve this problem? Check your e-mail inbox. But I don't know if the modification for Win9x-compatiblity is related to the OP's problem since he uses XP. Anyway, I don't think there will be any negative side-effect if you also use the updated version of the pex-file in Yagarto. The gcc in WinARM and WinXSCALE have not been configured with the registry-option (see arm-elf-gcc -v).
Stefan wrote: > Hello Michael > > perhaps you can change the gcc source the same way Martin Thomas did in > order to fix the _spawnv/_spawnvp problem. I get the very same error > with Yagarto on Win98SE which i got with older versions of WinARM too. > Matin patched the source with a change from the gcc CVS source tree and > the error was gone... I was now successful with Yagarto on Windows98SE. I used the same binary patch method for arm-elf-gcc.exe that is described for WinAVR already (*). The very same patch was applied to collect2.exe as well. Within Eclipse i needed to switch from internal (?) make to an external make program. I took the make from the utils-folder of WinAVR. I think this is a native MinGW make. One minor problem with Eclipse still exists - there is an exception when Eclipse is closed. (*) Beitrag "Re: avr-gcc: _spawnv: No such file or directory"
I have just installed yagarto yagarto-bu-2.17_gcc-4.1.1-c-c++_nl-1.14.0_gi-6.5.5.exe on vista into C:\sw\yagarto and I am faced to the same problem. I used process monitor from sysinternals to track down what is happening. Problem is that gcc-elf-arm process cannot find cc1.exe. I am attaching log, where gcc tries to find cc1.exe. It is almost successful with the first try, but problem is that it asks for cc1 without extension .exe. To be complete I am trying to compile simple main.c in c:\temp. I am going to download Windows debugging tools, so I can see stack of these system calls with symbols. It will show which API is used for this search.
For example request below has stack which I am attaching. It calls CRT function _stat32() which calls FindFirstFileA()... I hope it helps finally resolve issue. With regards Bronislav 14759 23:02:32,8982603 arm-elf-gcc.exe 3968 QueryDirectory C:\sw\yagarto\libexec\gcc\arm-elf\4.1.1\cc1 NO SUCH FILE Filter: cc1
Bronislav Gabrhelik wrote: > 14759 23:02:32,8982603 arm-elf-gcc.exe 3968 QueryDirectory > C:\sw\yagarto\libexec\gcc\arm-elf\4.1.1\cc1 NO SUCH FILE Filter: cc1 This is a bug in GCC 4.1.1. It called _spawnv incorrectly, and has been all along. However, previous versions of windows did not valid the parameters and it just happened to work. Vista does valid parameters, and so rejects the call. This error is fixed in GCC 4.1.2. If you do a google search theres some more information on the matter.
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.