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

Reply via email to