Hi, The at45db simulation component maintains one file for each node. I am just curious, how many nodes are you simulating?
Thanks Mike On Dec 9, 2009, at 1:28 AM, Yee Wei Law wrote: > Answering my own question, I found that on Snow Leopard, I have to increase > the max num of open files using "ulimit -n <number>", when I am using JHU's > simulation component for At45db. > > I confirm both gcc43 and gcc44 work with Razvan's ports. > > 2009/12/9 Yee Wei Law <[email protected]> > Correction: The package apple-gcc40 actually doesn't work. The compiler > cpp-apple-4.0 complains: "-c" is not a valid option to the preprocessor. I > thought I was using the compiler from apple-gcc40 but I was mistaken. > > I found that Apple's own gcc-4.0 and g++-4.0 don't work because TOSSIM will > complain about "mach-o, wrong architecture" when executing dlopen(). > > gcc-4.2 and g++-4.2, as have already been reported by others, don't work. > > The package gcc43 from Macports *might* work, because TOSSIM doesn't fail at > dlopen() but it segfaults. > > Therefore, despite Razvan's and Maciej's suggestion, none of the gcc > compilers work for me so far. My simulation code is a bit complicated but it > does work perfectly under Linux. Very strange... > > > 2009/12/8 Yee Wei Law <[email protected]> > > Thanks Razvan for setting up such a nice port. Just to summarize and add to > Razvan's advice: > > 1. The gcc 4.0 port that works is apple-gcc40 > 2. Both g++ and gcc need to be soft-linked to g++-4.0 and gcc-4.0 > respectively, otherwise the notorious error "file is not of required > architecture" will occur > 3. The file $TOSROOT/support/make/sim-sf.extra needs to be synchronized with > sim.extra w.r.t Darwin support, I hope the responsible maintainer can update > it > > Regards, > Yee Wei > > 2009/11/15 Razvan Musaloiu-E. <[email protected]> > > Hi! > > On Sat, 14 Nov 2009, Enzeneer wrote: > > Hey thats great! > Could you tell me what that means? What does it do? > > We need the '-D_FORTIFY_SOURCE=0' to avoid one set of errors (you can take if > you want to see :P). The 'export GCC=gcc-4.0' will ask the nesc to use the > gcc-4.0. If you run mig with the -v flag and look for gcc you'll how this is > propagated. > > Note: and sending this to the list too, in case some other people need the > info from below. > > > All the best! > Razvan ME > > Abhay > > > On Sat, Nov 14, 2009 at 3:05 PM, Razvan Musaloiu-E. <[email protected]> > wrote: > Hi! > > On Sat, 14 Nov 2009, Enzeneer wrote: > > I did change the GCC to gcc-4.0 in the null.rules. The error is > exactly as before. > > Just one thing, the error I am referring to occurs in the java > subdirectory of Oscilloscope. The oscilloscope application compiles > fine. > > Good point. A fix for that is the following: you need to add 'export > GCC=gcc-4.0' in the Makefile and '-D_FORTIFY_SOURCE=0' to the calls for mig > and ncg. > > -- > Razvan ME > > Thanks, > > Abhay > > > On Sat, Nov 14, 2009 at 1:01 PM, Razvan Musaloiu-E. <[email protected]> > wrote: > > Hi! > > On Sat, 14 Nov 2009, Enzeneer wrote: > > Sorry, doesn't work. > I tried changing the GCC=gcc-4.0 in the null.rules, but no avail. > > Yes, you need to set change the 'export GCC=gcc' to 'export GCC=gcc-4.0' in > support/make/null/null.rules. Sorry for forgeting to indicate this. > > How does it fail? With the same error as before? On my machine the 'make > null' in Oscilloscope shows something like this: > > $ make null > mkdir -p build/null > compiling OscilloscopeAppC to a null binary > ncc -o build/null/main.exe -Os -finline-limit=100000 -Wall -Wshadow > -fnesc-gcc=gcc-4.0 -Wnesc-all -target=null -fnesc-cfile=build/null/app.c > -DDEFINED_TOS_AM_GROUP=0x22 -DIDENT_APPNAME=\"OscilloscopeApp\" > -DIDENT_USERNAME=\"raz\" -DIDENT_HOSTNAME=\"lorien.local\" > -DIDENT_USERHASH=0xfcd5d9bcL -DIDENT_TIMESTAMP=0x4afeeff3L > -DIDENT_UIDHASH=0xc4745865L -D_FORTIFY_SOURCE=0 OscilloscopeAppC.nc -lm > /Users/raz/local/src/tinyos-2.x/tos/interfaces/TaskBasic.nc: In function > 'main': > /Users/raz/local/src/tinyos-2.x/tos/interfaces/TaskBasic.nc:56: warning: > control may reach end of non-void function > 'SchedulerBasicP$TaskBasic$postTask' being inlined > compiled OscilloscopeAppC to build/null/main.exe > 0 bytes in ROM > 0 bytes in RAM > > -- > Razvan ME > > On Sat, Nov 14, 2009 at 1:55 AM, Razvan Musaloiu-E. <[email protected]> > wrote: > > Hi! > > On Sat, 14 Nov 2009, Enzeneer wrote: > > Hi, > > It occurs whenever I try to build a Java program and target=null is > specified in the Makefile. For example in the Oscilloscope app. > > > Can you give another try of the latest CVS? I just committed a fix for > the > null too. :D > > All the best! > Razvan ME > > Now I found that if I change the target=telosb or target=$(PLATFORM), > then it builds without problem. > > The errors when target=null is specified are as below: > > make mig -target=null -java-classname=OscilloscopeMsg java > ../Oscilloscope.h oscilloscope -o OscilloscopeMsg.java In file > included from /usr/include/string.h:148, from > /Users/abhay/Developer/Source/tinyos-2.x/tos/system/tos.h:13: > /usr/include/secure/_string.h: In function `__inline_memcpy_chk': > /usr/include/secure/_string.h:58: warning: return makes pointer from > integer without a cast /usr/include/secure/_string.h: In function > `__inline_memmove_chk': /usr/include/secure/_string.h:69: warning: > return makes pointer from integer without a cast > /usr/include/secure/_string.h: In function `__inline_memset_chk': > /usr/include/secure/_string.h:80: warning: return makes pointer from > integer without a cast /usr/include/secure/_string.h: In function > `__inline_strcpy_chk': /usr/include/secure/_string.h:91: warning: > return makes pointer from integer without a cast > /usr/include/secure/_string.h: In function `__inline_stpcpy_chk': > /usr/include/secure/_string.h:103: warning: return makes pointer from > integer without a cast /usr/include/secure/_string.h: In function > `__inline_strncpy_chk': /usr/include/secure/_string.h:116: warning: > return makes pointer from integer without a cast > /usr/include/secure/_string.h: In function `__inline_strcat_chk': > /usr/include/secure/_string.h:127: warning: return makes pointer from > integer without a cast /usr/include/secure/_string.h: In function > `__inline_strncat_chk': /usr/include/secure/_string.h:139: warning: > return makes pointer from integer without a cast In file included from > /Users/abhay/Developer/Source/tinyos-2.x/tos/system/tos.h:14: > /usr/include/stdlib.h: At top level: /usr/include/stdlib.h:272: syntax > error before `^' /usr/include/stdlib.h:272: `type name' declared as > function returning a function /usr/include/stdlib.h:274: syntax error > before `^' /usr/include/stdlib.h:274: `type name' declared as function > returning a function /usr/include/stdlib.h:301: syntax error before > `^' /usr/include/stdlib.h:301: `type name' declared as function > returning a function /usr/include/stdlib.h:307: syntax error before > `^' /usr/include/stdlib.h:307: `type name' declared as function > returning a function /usr/include/stdlib.h:313: syntax error before > `^' /usr/include/stdlib.h:313: `type name' declared as function > returning a function /usr/include/stdlib.h:319: syntax error before > `^' /usr/include/stdlib.h:319: `type name' declared as function > returning a function In file included from > > > /Users/abhay/Developer/Source/tinyos-2.x/tos/system/SchedulerBasicP.nc:41, > from > > > /Users/abhay/Developer/Source/tinyos-2.x/tos/system/TinySchedulerC.nc:40: > > /Users/abhay/Developer/Source/tinyos-2.x/tos/platforms/null/hardware.h: > In function `__nesc_ntoh_afloat': > > > /Users/abhay/Developer/Source/tinyos-2.x/tos/platforms/null/hardware.h:22: > warning: pointer/integer type mismatch in conditional expression > > /Users/abhay/Developer/Source/tinyos-2.x/tos/platforms/null/hardware.h: > In function `__nesc_hton_afloat': > > > /Users/abhay/Developer/Source/tinyos-2.x/tos/platforms/null/hardware.h:27: > warning: pointer/integer type mismatch in conditional expression In > file included from > > > /Users/abhay/Developer/Source/tinyos-2.x/tos/system/TinySchedulerC.nc:40: > In component `SchedulerBasicP': > > /Users/abhay/Developer/Source/tinyos-2.x/tos/system/SchedulerBasicP.nc: > In function `Scheduler.init': > > > > /Users/abhay/Developer/Source/tinyos-2.x/tos/system/SchedulerBasicP.nc:117: > warning: pointer/integer type mismatch in conditional expression > failed to parse message file ../Oscilloscope.h make: *** > [OscilloscopeMsg.java] Error 1 > > The same thing with target=telosb: > > make > mig -target=telosb -java-classname=OscilloscopeMsg java > ../Oscilloscope.h oscilloscope -o OscilloscopeMsg.java > ncg -target=telosb -java-classname=Constants java ../Oscilloscope.h > NREADINGS DEFAULT_INTERVAL -o Constants.java > javac *.java > jar cf oscilloscope.jar *.class > > Hope this helps. > > Abhay > > On Fri, Nov 13, 2009 at 11:52 PM, Razvan Musaloiu-E. > <[email protected]> > wrote: > > Hi! > > On Fri, 13 Nov 2009, Enzeneer wrote: > > Cool! > This works, but I still have problems compiling some of the other > applications that reference stdlib.h. > Can you point me to some information about mig? How does it select the > gcc version? > > Can you indicate the steps to reproduce this problem? :P The stuff in > RadioCountToLeds worked fine for me. > > -- > Razvan ME > > On Fri, Nov 13, 2009 at 9:24 PM, Razvan Musaloiu-E. > <[email protected]> > wrote: > > Hi! > > On Fri, 13 Nov 2009, Maciej Franecki wrote: > > it seems that I (maybe partially..) solved it. > > > That's what I've done: > installed gcc 4.3.4 from macports > changed gcc soft link (in /usr/bin) to point the new version > > and: > *** Successfully built micaz TOSSIM library > > > I committed some fixes that make it possible to use the gcc 4.0.1 that > comes with 10.6. If you update to the latest CVS and edit the GCC from > sim.extra should to point to gcc-4.0 it should work fine. > > The ugly details: 10.6 comes with something called C Blocks. The gcc 4.2.1 > has them enable by default and disabling them is a little tricky (passind > -D__BLOCKS__=0 generates a warning). The good news is that gcc 4.0.1 does > not so it works fine. The only other thing I did was to add to the flags > -D_FORTIFY_SOURCE=0 (to avoid another set of errors). > > [1] http://thirdcog.eu/pwcblocks/ > > All the best! > Razvan ME > > > did some basic tests in python and (as for now) it seems to be > working. > > > Cheers, > Maciej > > _______________________________________________ > Tinyos-help mailing list > [email protected] > > > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > > > > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
