| Author |
Message |
|
|
 Posted: Feb 10, 2012 - 12:47 AM |
|
Joined: Apr 12, 2005
Posts: 1050
|
|
I have a new installation of WinAVR-20100110 and studio 4 sp3.
When I compile the program, I get no errors with the program itself, but I get an odd failure quoted below. I am running this on a Vista 64 bit machine.
Any help would be appreciated.
Quote:
Build started 9.2.2012 at 19:39:08
0 [main] sh 4652 sync_with_child: child 4592(0x11C) died before initialization with status code 0x0
14062 [main] sh 4652 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex ESR.elf ESR.eep || exit 0
0 [main] sh 4252 sync_with_child: child 3416(0x114) died before initialization with status code 0x0
98483 [main] sh 4252 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
make: [ESR.eep] Error 128 (ignored)
avr-objdump -h -S ESR.elf > ESR.lss
0 [main] sh 2280 sync_with_child: child 2592(0x114) died before initialization with status code 0x0
50450 [main] sh 2280 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
make: *** [ESR.lss] Error 128
Build failed with 1 errors and 0 warnings...
|
|
|
| |
|
|
|
|
|
|
Posted: Feb 10, 2012 - 05:14 AM |
|
Joined: Jan 14, 2008
Posts: 1157
Location: San Diego
|
|
I believe this problem has come up before but I can't remember the solution.
Try doing a search of the forum. |
_________________
~~John
TWI C source code
|
| |
|
|
|
|
|
|
Posted: Feb 10, 2012 - 01:03 PM |
|
Joined: Apr 12, 2005
Posts: 1050
|
|
I did a search and only came up with some pretty old stuff dating to 2008 and earlier. In one, they point to
http://www.madwizard.org/electronics/articles/winavrvista which identifies the (only?) problem and suggests a fix. Unfortunately, this is pretty old info, and the repaired files may not be applicable.
I got Studio 4.19 with the AVR toolchain (don't know how old the tool chain is) to properly build the program. When I installed WinAVR-20100110 over that installation, then builds fail using both the tool chain and WinAVR-20100010!
So, there is something in the path of the toolchain that is fixed and when the winavr path supercedes that, then it fails. Interesting. I wonder what the file is, and whether it is able to be copied to WinAVR-20100110.
Do you think I can lift one or more programs from the AVR Toolchain and put them in the WinAVR location to get the build to work? Which programs or files should I try? I don't want to make the substitution so complete that I start to compile with the Atmel AVR Toolchain without knowing it.
-Tony |
|
|
| |
|
|
|
|
|
|
Posted: Feb 10, 2012 - 01:36 PM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| Get rid of the "Toolchain" all together. WinAVR-20100110 and Studio 4.19 work well together. |
_________________
|
| |
|
|
|
|
|
|
Posted: Feb 10, 2012 - 04:17 PM |
|
Joined: Apr 12, 2005
Posts: 1050
|
|
|
clawson wrote:
Get rid of the "Toolchain" all together. WinAVR-20100110 and Studio 4.19 work well together.
That is the goal here!
But WinAVR gives the build error I am discussing here. I am using a Vista 64bit computer and SOMETHING in the build process is causing an error. It seems as if compilation is OK, but maybe avr-nm.exe or avr-objdump.exe is causing trouble. Something is different with the Atmel AVR toolchain that DOES work, but I cant tell what. Simply moving the Atmel-supplied avr-nm and avr-objdump to WinAVR does not fix the problem. Maybe the toolchain does not even use avr-nm at all, and maybe that is the problem.... I can't tell. Also, there is no MSys DLL file supplied with the toolchain, and that was implicated as being the build problem several years ago. So, I am not sure where to go with this to be able to use WinAVR!
-Tony |
|
|
| |
|
|
|
|
|
|
Posted: Feb 10, 2012 - 04:22 PM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
It seems as if compilation is OK
No it doesn't - the error you show occurs immediately after "Build Started". For the record, this is what a "normal" build looks like:
Code:
Build started 10.2.2012 at 16:20:11
avr-gcc -mmcu=atmega16 -Wall -gdwarf-2 -std=gnu99 --save-temps -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT test.o -MF dep/test.o.d -c ../test.c
avr-gcc -mmcu=atmega16 -Wl,-Map=test.map test.o -lm -o test.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature test.elf test.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex test.elf test.eep || exit 0
avr-objdump -h -S test.elf > test.lss
BTW you do know about the issue of 4.19 not finding WinAVR any more don't you? It has to be set manually in Project Options for each project now. (thanks Atmel). |
_________________
|
| |
|
|
|
|
|
|
Posted: Feb 10, 2012 - 05:25 PM |
|
Joined: Apr 12, 2005
Posts: 1050
|
|
|
Quote:
BTW you do know about the issue of 4.19 not finding WinAVR any more don't you? It has to be set manually in Project Options for each project now. (thanks Atmel).
Yes, and I have used it. I have tried several variations on a theme for the installation and build. If I install WinAVR on top of a properly functioning Studio + Atmel AVR Toolchain (but make no changes to the Studio project), then the build (with the Atmel Toolchain!) fails. If I remove the WinAVR entries from the path, then the same build works again.
If I use a hybrid build with specifying the WinAVR version of avr-gcc.exe, but specify the Atmel-supplied Make.exe, without winavr in the path, then compilation works. If I move the Atmel-supplied Make.exe to the Winavr location and use all other winavr files, with the proper winavr path, the build still fails.
So, it is something in the WinAVR path that is also used in the Atmel Toolchain build that causes the problem. But what?
I replaced the winAVR avr-nm, avr-objdump, with the Atmel-supplied versions, but still get the build error when using WinAVR. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 10, 2012 - 07:51 PM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| Remove everything from PATH apart from the WinAVR location with PATH \winavr\bin;winavr\utils\bin so that nothing but avr-gcc can be found then try again. |
_________________
|
| |
|
|
|
|
|
|
Posted: Feb 11, 2012 - 12:16 PM |
|
Joined: Apr 12, 2005
Posts: 1050
|
|
Yep still a no-go. There is something in the WinAVR system that is different from the Atmel AVR Toolchain that is unhappy with Vista64, like most of us....
Still unable to compile with WinAVR. :< |
|
|
| |
|
|
|
|
|
|
Posted: Feb 11, 2012 - 03:17 PM |
|
Joined: Oct 29, 2006
Posts: 2689
|
|
|
Spamiam wrote:
Yep still a no-go. There is something in the WinAVR system that is different from the Atmel AVR Toolchain that is unhappy with Vista64, like most of us....
Still unable to compile with WinAVR. :<
Can you build from the command line with an MFILE file or other make file?
Can you build by typing in the commands directly?
This is why Athena invented cut and paste. |
_________________
Michael Hennebry
Iluvatar is the better part of Valar.
|
| |
|
|
|
|
|
|
Posted: Feb 12, 2012 - 02:41 PM |
|
Joined: Apr 12, 2005
Posts: 1050
|
|
Well, I did not try manually compiling yet, but I did manage to isolate the offending program. I think....
I noticed that if the WinAVR folders are in the path, anywherre in the path, then a build using the Atmel AVR Toolchain fails! The failure is identical to what happens with a WinAVR build.
So, there is something that even the AVR toolchain will use, if available, that fails, but it is not essential to the build. Very odd.
So, I moved the Atmel Toolchain "bin" folder to a new folder and set the path to point there rather than the AVR toolchain folder. I then did a build with no WinAVR references in the path. It worked. I then added the WinAVR folders back into the path until the build failed. Then I removed files from the WinAVR folder (.../utils/bin) until the build didn't fail.
I found that (not surprisingly) Msys-1.0.dll was used. I also found that sh.exe was using Msys. If I renamed sh.exe, then the build works. If I kept sh.exe as-is, the build failed.
So, why is the AVR toolshain trying to use sh.exe, but the build works without it?
I will try a WinAVR build without sh.exe.
-Tony
ADDENDUM: A WinAVR build DOES work as long as sh.exe is not to be found in the path |
Last edited by Spamiam on Feb 12, 2012 - 05:34 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Feb 12, 2012 - 04:18 PM |
|
Joined: Oct 29, 2006
Posts: 2689
|
|
|
Spamiam wrote:
I found that (not surprisingly) Msys-1.0.dll was used. I also found that sh.exe was using Msys. If I renamed sh.exe, then the build works. If I kept sh.exe as-is, the build failed.
Could this be an instance of dll hell?
Once upon a time, part of winAVR required a cygin
dll and version issues sometimes bit people.
Do you have more than one Msys dll?
Quote:
So, why is the AVR toolshain trying to use sh.exe, but the build works without it?
|
_________________
Michael Hennebry
Iluvatar is the better part of Valar.
|
| |
|
|
|
|
|
|
Posted: Feb 12, 2012 - 05:31 PM |
|
Joined: Apr 12, 2005
Posts: 1050
|
|
|
skeeve wrote:
Do you have more than one Msys dll?
No, the only MSys dll was mSys-1.0.dll which was in the WinAVR ...\utils\bin folder.
I tried that old (2007) "fixed" mSys-1.0.dll file that was referred to in the old thread about the problem. That did not fix anything.
-Tony |
|
|
| |
|
|
|
|
|
|
Posted: Feb 12, 2012 - 06:32 PM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
I just checked my Winavr\utils\bin and found:
Code:
root@ws-czc1138h0b:/windows/WinAVR-20100110/utils/bin# ls ms* -ld
-rwxrwxrwx 1 clawson clawson 781616 2010-01-19 18:08 msys-1.0.dll
-rwxrwxrwx 1 clawson clawson 781616 2010-01-19 18:08 msys-1.0.dll.old
When I use vbindiff to compare those two it seems that apart from a few other differences near the start "old" has every 0x71 replaced by 0x30 in the other.
Now I'm not sure where this came from or why I changed it but I have a feeling this was done to fix some serious problem.
BTW these are the MD5's to identify the files:
Code:
root@ws-czc1138h0b:/windows/WinAVR-20100110/utils/bin# for f in msy* ; do md5sum ${f} ; done
09aa055ebfb277fb5e8b2fa463cdb712 msys-1.0.dll
c31035745576abd788e75df2376252d9 msys-1.0.dll.old
=============================================================================
(and sorry for the confusion in the above - but that is a Linux view of the same files I actually use in Windows - it's just Linux is better for this kind of thing! My /windows/ maps to E: in Windows) |
_________________
|
| |
|
|
|
|
|
|
Posted: Feb 12, 2012 - 10:29 PM |
|
Joined: Apr 12, 2005
Posts: 1050
|
|
Back in 2007, from what I have read elsewhere, Msys-1.0.dll was "re-based". I am not sure what that means, but I suspect that it is the difference you found. I am not sure why "re-basing" the executable code would make a difference. The one thing I do know is that it did not make it work for my Vista 64bit system.
Still don't know why eliminating sh.exe will still allow the build to proceed properly, nor what is lost by not having sh.exe function.
-Tony |
|
|
| |
|
|
|
|
|
|
Posted: Feb 13, 2012 - 09:38 AM |
|
Joined: Jul 18, 2005
Posts: 62922
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
Still don't know why eliminating sh.exe will still allow the build to proceed properly, nor what is lost by not having sh.exe function.
sh is invoked by make for running external commands such as rm. Try doing a "make clean" and you may find it's unable to execute the "rm -fr" command. |
_________________
|
| |
|
|
|
|
|
|
Posted: Feb 13, 2012 - 01:21 PM |
|
Joined: Apr 12, 2005
Posts: 1050
|
|
"make clean" worked fine.
From what I have further read, make.exe will look for sh.exe in the path and if not found, it will use the default shell, which on windows machine (at least this one), is cmd.exe.
I also read that if you set an environment variable to: "SHELL = cmd.exe", then make.exe will automatically use cmd.exe for the shell. I tried this, but I got the same build error. So I suspect that make.exe is not influenced by a "SHELL =" environment setting.
-Tony |
|
|
| |
|
|
|
|
|
|
Posted: Feb 13, 2012 - 04:44 PM |
|
Joined: Oct 29, 2006
Posts: 2689
|
|
|
Spamiam wrote:
I also read that if you set an environment variable to: "SHELL = cmd.exe", then make.exe will automatically use cmd.exe for the shell. I tried this, but I got the same build error. So I suspect that make.exe is not influenced by a "SHELL =" environment setting.
You might try SHELL=cmd.exe on the command line or in the make file itself. |
_________________
Michael Hennebry
Iluvatar is the better part of Valar.
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
