Hi, I've sent these questions to the lpc2000 yahoo list recently, but perhaps this is the more appropriate forum. They both relate to my recent attempt to upgrade from WinARM (containing arm-elf-gcc 4.0.0) to a more recent version. Issue 1: Eclipse compile crash A simple make to do an intermediate compile (.c->.o) fails where it used to work with fine the older environment. The error I get is: make -k all adc.c rm -f adc.o arm-elf-gcc -c -mcpu=arm7tdmi-s -I. -ggdb2 -isystem "../../newlib5.1" -isystem "C:/WinARM/arm-elf/include" -isystem "../../newlib5.1/rdcf2/include" -O0 -fsigned-char -funsigned-bitfields -fshort-enums -ftabstop=4 -fpack-struct -mstructure-size-boundary=32 -msingle-pic-base -Wall -Wstrict-prototypes -Wno-format-extra-args -Wno-format-zero-length -Werror-implicit-function-declaration -Wa,-adhlns=adc.lst -Wpadded -I..\include -MD -MP -MF .dep/adc.o.d adc.c -o adc.o This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. make: *** [adc.o] Error 3 make: Target `all' not remade because of errors. This occurs for both WinARM 4.1.2 and for Yagarto 4.2.1 (latest of each) providing the arm-elf-gcc exe above. "make.exe" can be either WinARM utils version. I did this by changing PATH in the C/C++ Make Project->Environment in Eclipse. If I type "make all" in a DOS prompt, with the appropriate PATH set as above, it works fine in all cases. It only bombs if done through Eclipse. Based on Google seaching, I thought it may have something to do with heap size available to Eclipse, so I tried increasing this in eclipse.ini. No help. I also tried upgrading the Eclipse I was running from 3.2.0 to 3.3.0 from the latest Yagarto-IDE download, but exactly the same error. Issue 2: libc difference between WinARM and Yagarto. I had problems in the exceutable when created with Yagarto 4.2.1. The problems do not occur with WinARM 4.1.2. As far as I can tell, by looking at the map and lss files output, though both distros are newlib based, only WinARM is newlib_lpc compatible. If I follow the calling sequence of say "open()" for Yagarto: open()->_open -> _swiopen() which cases a undesirted SWI (reset in my case) newlib_lpc by contrast provides the stub _open_r, which is replaced in WinARM but ignored by Yagarto. Perhaps Yagarto hasn't been compiled with the compile switch -DREENTRANT_SYSCALLS_PROVIDED as recommended by Bill Gattliff ? http://venus.billgatliff.com/node/3 Issue 3: whence libg.a ? It seems libg.a is libc.a with debugging information included. Why, if I only ever specify -lc to the link phase (not -lg) do I still get items in my map file included from libg.a ? Is this perhaps implied when you specfiy other debug options along with -lc ? More a curiousity than a real problem as it seems libg and libc are identical on WinARM and Yagarto. Cheers, Bruce
Bruce Paterson wrote: > Issue 1: Eclipse compile crash Sorry, I don't use Eclipse that often an so far I have not seen this issue. So I currently can not help with this one. > Issue 2: libc difference between WinARM and Yagarto. > > I had problems in the exceutable when created with Yagarto 4.2.1. The > problems do not occur with WinARM 4.1.2. As far as I can tell, by > looking at the map and lss files output, though both distros are newlib > based, only WinARM is newlib_lpc compatible. > If I follow the calling sequence of say "open()" for Yagarto: > open()->_open -> _swiopen() which cases a undesirted SWI (reset in my > case) It seems that the standard syscalls are used with the Yagarto build. > newlib_lpc by contrast provides the stub _open_r, which is replaced in > WinARM but ignored by Yagarto. Perhaps Yagarto hasn't been compiled with > the compile switch -DREENTRANT_SYSCALLS_PROVIDED as recommended by Bill > Gattliff ? > http://venus.billgatliff.com/node/3 Yes, the newlib in WinARM is build with newlib provided syscalls disabled and to use reentrant syscalls. I use this setup since the first WinARM package which I created to be compatible with newlib-lpc "out of the box" for may own experiments. AFAIK Michael Fischer uses the "standard configuration" for newlib. As a workaround you may remove the syscalls.o object from the used "Yagarto"-libc.a, but this might be an ugly hack. There might be better solutions with special linker-options and/or library grouping but so far I had to need to investigate this (obviously I'm using WinARM). > Issue 3: whence libg.a ? Sorry, not quick answer from my side on this, I have not used yet used option -lg/linked with libg.a. Martin Thomas
Bruce Paterson wrote: > > Issue 1: Eclipse compile crash > > This may be too late to help you, but I'll post here anyway since this is the only place I've seen this problem raised, maybe it'll help others. I'm trying Yagarto for the first time (for Atmep AT91SAM7S), and had the same symptoms. I noticed that "make clean" generated a bash error 'can't find /tmp' or similar. My Eclipse environment included TMP=C:\DOCUME~1\username\LOCALS~1\Temp (project/properties/C C++ Build/environment 'Select'), presumably picked up from the DOS environment. Adding TMP to the Eclipse environment variables, changing it to the full Windows path (C:\Documents and Settings\username\Local Settings\Temp) and selecting 'Replace native environment...' fixed the problem. Surprisingly, the spaces in the path don't seem to break anything ! BTW, I also had problems with multiple versions of make in the search path - including Borland's 'make' which bears no resemblance to gnu make. The safest solution is to put an explicit PATH in Eclipse, again with 'Replace...'. Now I'm just waiting for our so-called purchasing department to expedite delivery of an ARM evaluation kit... I hope this helps, either Bruce or some other poor guy in the future. Andy
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.