Contiki errors for certain examples - build

Hello there I am trying to build the examples given as part of the Contiki-2.6 RTOS. The directory path is : contiki/contiki-2.6/examples/ping-ipv6
I am trying to build the example ping-ipv6 for TI's SMARTRF05-EB, the SoC being 2530.
1) contiki/contiki-2.6/examples/ping-ipv6# make TARGET=cc2530dk clean
2) contiki/contiki-2.6/examples/ping-ipv6# make TARGET=cc2530dk
but after executing the above 2 commands I get the following error ..I have just included the last part of information from the huge build output. Please let me know how to resolve it. Please note I am able to build the hello-world example and also the cc2530dk example using the above 2 commands.
30dk/nullradio.rel -Wp,-MMD,obj_cc2530dk/nullradio.d,-MQ,obj_cc2530dk/nullradio.rel
../../core/dev/nullradio.c:14: warning 85: in function prepare unreferenced function argument : 'payload'
../../core/dev/nullradio.c:14: warning 85: in function prepare unreferenced function argument : 'payload_len'
../../core/dev/nullradio.c:20: warning 85: in function transmit unreferenced function argument : 'transmit_len'
../../core/dev/nullradio.c:33: warning 85: in function read unreferenced function argument : 'buf'
../../core/dev/nullradio.c:33: warning 85: in function read unreferenced function argument : 'buf_len'
sdcc --codeseg BANK1 -DCONTIKI=1 -DCONTIKI_TARGET_CC2530DK=1 -DUIP_CONF_IPV6=1 -DUIP_CONF_IPV6_RPL=1 --model-huge --stack-auto --std-c99 -DCC2530_LAST_FLASH_BANK=7 -DHAVE_SDCC_BANKING -I. -I../../platform/cc2530dk/. -I../../platform/cc2530dk/dev -I../../cpu/cc253x/. -I../../cpu/cc253x/dev -I../../core/dev -I../../core/lib -I../../core/net -I../../core/net/mac -I../../core/net/rime -I../../core/net/rpl -I../../core/sys -I../../core/cfs -I../../core/ctk -I../../core/lib/ctk -I../../core/loader -I../../core/. -I../../apps/ping6 -I../../platform/cc2530dk/ -c ../../apps/ping6/ping6.c -o obj_cc2530dk/ping6.rel -Wp,-MMD,obj_cc2530dk/ping6.d,-MQ,obj_cc2530dk/ping6.rel
../../apps/ping6/ping6.c:92: warning 112: function 'scanf' implicit declaration
../../apps/ping6/ping6.c:99: warning 112: function 'scanf' implicit declaration
../../apps/ping6/ping6.c:92: error 101: too many parameters
../../apps/ping6/ping6.c:99: error 101: too many parameters
../../apps/ping6/ping6.c:153: warning 85: in function ping6handler unreferenced function argument : 'ev'
../../apps/ping6/ping6.c:153: warning 85: in function ping6handler unreferenced function argument : 'data'
make: *** [obj_cc2530dk/ping6.rel] Error 1

It seems it has been a long time since the question is asked, but still...
The short answer is that scanf() function is not supported for the target cc2530dk. Instead of scanf(), uart0_set_input() function from /dev/uart0.h or serial_line_event_message event from dev/serial-line.h libraries should be used to read input from UART.
P.S.: There may be other similar incompatibilities as well even if you fix that.

For platforms that don't have scanf, you may want to edit apps/ping6/ping6.c and set MAC_DEBUG to 1. That way you'll be able to hard-code the IPv6 address you want to ping (in the #if MACDEBUG)

Related

Grib_api options in f90

As we know if I want to get the levelType of each message in a grib file.
I could use this below in f90:
grib_get(igrib(i), 'levelType', ltype)
But when fail it will cause a eccodes error and can't gei the value. As the document of grib_api on the site of ECMWF. I found an option 'f' to force the execution not to fail on error and write 'not_found' string to ltype paramters. My quastion is how can i usethis force option in f90?

VS2013 build fails if I output "ERROR" in the post build step - I think

This is a bit of an odd one, and I tried to Google it but didn't have much luck. Also, I apologize for the long lead-in... but I think it's all info necessary to understand what's happening?
I'm working in C++, using Visual Studio 2013, and I have my own unit test implementation. The test project is part of the solution, and there is a post build event which runs them (using the executable which was just built), and if that even returns non-0 then the build fails (as it should).
I also have my own macro-based output system which uses OutputDebugString to print to the output window in the development environment, so I can use statements like these:
AI_ERROR("Some ERROR message with C-style %s", "arguments");
AI_WARN("Some ERROR message with C-style %s", "arguments");
AI_LOG("Some ERROR message with C-style %s", "arguments");
AI_ERROR_CONFIG("Some ERROR message with C-style %s", "arguments");
AI_WARN_CONFIG("Some ERROR message with C-style %s", "arguments");
AI_LOG_CONFIG("Some ERROR message with C-style %s", "arguments");
Which will result in this output when I run the executable directly:
(0.0000) tesaitest.cpp:87 ERROR: Some ERROR message with C-style arguments
(0.0000) tesaitest.cpp:88 WARNING: Some ERROR message with C-style arguments
(0.0000) tesaitest.cpp:89 LOG: Some ERROR message with C-style arguments
(0.0000) tesaitest.cpp:90 ERROR (CONFIGURATION): Some ERROR message with C-style arguments
(0.0000) tesaitest.cpp:91 WARNING (CONFIGURATION): Some ERROR message with C-style arguments
(0.0000) tesaitest.cpp:92 LOG (CONFIGURATION): Some ERROR message with C-style arguments
That all works - so far so good.
Here's where it gets a little weird. If I run the executable for the tests directly, then it runs, and it prints the messages I showed above, and it returns 0 - which is expected, since I never wrote any code to do anything different. However, when I compile and the tests are run as a post build event, it returns -1. If I comment out the two error messages (the AI_ERROR and the AI_ERROR_CONFIG) then it returns 0, even though the output string still has the word "ERROR" in it. This is actually the behavior I want - but this is a multi-compiler project, and I want to make sure that execution is consistent, so I want to make sure that I'm the one making it happen, not just the dev environment doing it for me.
Another thing that I notice is that in the output that I get when I compile, the words "error" and "warning" are lower case, but "log" is not - and they are not lowercase in the original code. Here's what that output looks like:
1>(0.0000) tesaitest.cpp : 87 error : Some ERROR message with C-style arguments
1>(0.0000) tesaitest.cpp : 88 warning : Some ERROR message with C-style arguments
1> (0.0000) tesaitest.cpp:89 LOG: Some ERROR message with C-style arguments
1>(0.0000) tesaitest.cpp : 90 error (CONFIGURATION): Some ERROR message with C-style arguments
1>(0.0000) tesaitest.cpp : 91 warning (CONFIGURATION): Some ERROR message with C-style arguments
1> (0.0000) tesaitest.cpp:92 LOG (CONFIGURATION): Some ERROR message with C-style arguments
That part of the string is passed into the print function as an enum (either Error or ConfigError), but then I use vsnprintf_s to compile the whole message into a single char buffer before I pass it into OutputDebugString.
Of course, for added fun, because this only happens during compile, and not when I run the executable directly, I can't catch it in the debugger.
So... does anybody understand how/why MS is determining that these are errors and changing the return value? Is there a setting where I can turn that off? As I said, since this is a multi-compiler project, and also because I might want to be able to have cases where error messages don't actually represent failed tests (i.e. I want to test that error messages to get generated on bad input) I'd rather that I had full control over the return value...

Error on line 50: attempt to give DATA in type-declaration

I am try to compile FORTRAN 77 code and I have problems like this.
integer row(nnzmax+nszero),column(nnzmax+nszero),
+ ireg(nximax),florsm(nzimax)/nzimax*2/
real lambda,imodel(nximax,nzimax),dm(nmmax),
+ dum1(nmmax),dum2(nmmax),data(ndmax+nsconst),
+ anz(nnzmax+nszero),ibmodel(nximax,nzimax),
+ smwz(nzimax)/nzimax*-1./,spwz(nzimax)/nzimax*-1./
Error on line 50: attempt to give DATA in type-declaration
Error on line 52: attempt to give DATA in type-declaration
I used to work with this code,but it has been compiled with Intel Fotran Compiler. I have moved to other country so I do not have ifort installed here. I am using fort77 now. Should I try with some compilation options or?I have used this script to compile app .f from this folder.
#! /bin/csh -f
set list=`ls *.f`
set FLAG="-o"
echo $list
foreach file (${list})
echo $file
f77 ${file} ${FLAG} ${file:r}
mv ${file:r} ../bin/.
end
I have changed declarations like this:
integer row(nnzmax+nszero),column(nnzmax+nszero),
+ ireg(nximax),florsm(nzimax),
+ data florsm /nzimax*2/
real lambda,imodel(nximax,nzimax),dm(nmmax),
+ dum1(nmmax),dum2(nmmax),data(ndmax+nsconst),
+ anz(nnzmax+nszero),ibmodel(nximax,nzimax),
+ data smwz /nzimax*-1./,
+ data spwz /nzimax*-1./
But still I got
Error on line 50: attempt to give DATA in type-declaration
Error on line 53: attempt to give DATA in type-declaration
Error on line 385: Declaration error for smwz: used as variable
Error on line 385: Declaration error for smwz: may not appear in namelist
Error on line 385: Declaration error for spwz: used as variable
Error on line 385: Declaration error for spwz: may not appear in namelist
This fragment, and the later similar ones
florsm(nzimax)/nzimax*2/
looks like a non-standard way of initialising a variable with a sort-of data statement merged into the declaration. A more standard approach would separate the two, something like
florsm(nzimax)
...
data florsm /nzimax*2/
One of the beauties of working with the Intel Fortran compiler is its long history; along the way it has picked up, and continues to accept, all sorts of non-standard features. I'm guessing that this is one of those and is not acceptable to the other compiler you mention.
Of course, this seems to be what the error statement seems to be telling us.
A standard replacement might be
florsm(nzimax) = 2
but that takes advantage of a Fortran 90 feature which something called fort77 might not understand either.

C++ no 'object' file generated

This is some code to get an environment variable from inside Qt, however, it seems Qt's QProcessEnvironment::systemEnvironment() only reflect a new environment variable change after reboot. So I am thinking about using getenv.
However I got "error C2220: warning treated as error - no 'object' file generated" from this :
QProcessEnvironment env = QProcessEnvironment::systemEnvironment();
const QString ENGINE_ROOT = env.value("ENGINE_ROOT", "") != "" ?
env.value("ENGINE_ROOT","") : QString(getenv("ENGINE_ROOT"));
Don't tell me something like disable /WX or lower W4 to W3, I don't want to hear this, I want to know exactly what cause
no 'object' file generated
.
"error C2220: warning treated as error - no 'object' file generated"
The error already answers your question:
A warning was generated.
Because you have told the compiler to treat warnings as errors, an error occurred.
Because an error occurred, the compiler did not generate an object file.
If you want to know what the original warning means, then you need to ask us about that warning.
I just had this problem. The real source of the confusion is that Microsoft Visual Studio lists the
error C2220: warning treated as error - no 'object' file generated
line separately from the warnings--sometimes even before the warnings--so it is not immediately apparent that the error is related to the listed warnings.
Fix all warnings listed to fix this problem.
I'll address the underlying question instead of the compilation problem.
Environment variables for any process are copied from those of its parent process when your new process is started. From that point, the only thing that can modify them is your process yourself.
In practical terms, this means that going to the Windows dialog box to change environment variables does not change those values for any existing processes. Those changes are applied to the explorer.exe process, and then any new processes launched from Explorer.
There is a possible way for a Windows application to get notified of changes made to environment variables made by Explorer. See How to modify the PATH variable definitely through the command line in Windows for details.
in my case, eliminating all useless 'object' will deal this erro

Strange output and branch warning when compiling

I compile a fortran 77 code using gfortran and get the following error:
10 open (23,file=outfile,status='old',access='append',err=10)
1
Warning: Branch at (1) may result in an infinite loop
This happens several times.
One of the output files looks like the following:
^L6a10È <90> ) &<9b>LÓLÓLÕ<91><90> <90> <90> È <8e><9b>LÓLÓLÕ<93>2
!MERCURY ¢¤õ/!ô<8a><8a><90> ÿ<90> ÿ<90> ÿÌÖÏ©ü}M<91>
"VENUS «}>±{©±<8b><90> ÿ<90> ÿ<90> ÿʺ93¿<8d>d<91>
However, it should just look like a table of text.
Any ideas?
Your line of code
10 open (23,file=outfile,status='old',access='append',err=10)
specifies that the open statement should transfer control to itself (label 10) in case an error is encountered, so any error could trigger an infinite loop. It also suppresses the output of error messages. If you want to just check for an error status, I would suggest using the iostat and/or iomsg (Fortran 2003) arguments:
open (23, file=outfile, status='old', access='append', iostat=ios, iomsg=str)
Here ios is an integer that will be zero if no errors occur and nonzero otherwise, and str is a character variable that will record the corresponding error message.
The err= argument in your open statement specifies a statement label to branch to should the open fail for some reason. Your code specifies a branch to the line labelled 10 which happens to be the line containing the open statement. This is probably not a good idea; a better idea would be to branch to a line which deals gracefully with an error from the open statement.
The warning from gfortran is spot on.
As to the apparent garbage in your output file, without sight of the code you use to write the garbage (or what you think are pearls perhaps) it's very difficult to diagnose and fix that problem.