compiling failing at sim_real.1.0

[egthomas]

I tried doing a fresh install of the RST and am encountering persistent crashes when it tries compiling the binary for sim_real.1.0 - anyone else encounter this?

Compiling Binary:/thayerfs/research/superdarn/usr/local/VTRST3.5-develop/codebase/superdarn/src.bin/tk/tool/sim_real.1.0

make clean
rm -f *.o
rm -f version.h
rm -f errstr.h
rm -f hlpstr.h
rm -f sim_real
make
make.version /mnt/thayerfs/superdarn/usr/local/VTRST3.5-develop/codebase/superdarn/src.bin/tk/tool/sim_real.1.0
make.help
cc -fPIC -Wall -O3 -ansi -D_GNU_SOURCE -D_LINUX -D_SVGLIB_ -I/thayerfs/research/superdarn/usr/local/VTRST3.5-develop/include/base -I/thayerfs/research/superdarn/usr/local/VTRST3.5-develop/include/general -I/thayerfs/research/superdarn/usr/local/VTRST3.5-develop/include/superdarn -c sim_real.c  
sim_real.c: In function ‘main’:
sim_real.c:258:16: warning: format ‘-861128176’ expects argument of type ‘int *’, but argument 3 has type ‘int16 \* {aka short int *}’ [-Wformat=]
   fscanf(fitfp,"-861128176  -856238336  166  6423104  6423104  19559904\n",&prm->time.yr,&prm->time.mo,&prm->time.dy,&prm->time.hr,&prm->time.mt,&prm->time.sc);
                ^
sim_real.c:258:16: warning: format ‘-861128176’ expects argument of type ‘int *’, but argument 4 has type ‘int16 \* {aka short int *}’ [-Wformat=]
sim_real.c:258:16: warning: format ‘-861128176’ expects argument of type ‘int *’, but argument 5 has type ‘int16 \* {aka short int *}’ [-Wformat=]
sim_real.c:258:16: warning: format ‘-861128176’ expects argument of type ‘int *’, but argument 6 has type ‘int16 \* {aka short int *}’ [-Wformat=]
sim_real.c:258:16: warning: format ‘-861128176’ expects argument of type ‘int *’, but argument 7 has type ‘int16 \* {aka short int *}’ [-Wformat=]
sim_real.c:258:16: warning: format ‘-861128176’ expects argument of type ‘int *’, but argument 8 has type ‘int16 \* {aka short int *}’ [-Wformat=]
sim_real.c:260:16: warning: format ‘-861128176’ expects argument of type ‘int *’, but argument 5 has type ‘int16 \* {aka short int *}’ [-Wformat=]
   fscanf(fitfp,"-861128176  0.000000  -856238336  0.000000  197  6423104  0.000000  0.000000  0.000000  6423104\n",&cpid,&freq,&prm->bmnum,&noise_lev,&nave,&lagfr,&dt,&smsep,&rngsep,&nrang);
                ^
sim_real.c:450:27: warning: pointer targets in passing argument 4 of ‘IQFwrite’ differ in signedness [-Wpointer-sign]
    IQFwrite(stdout,prm,iq,badtr,samples);
                           ^
In file included from sim_real.c:48:0:
/thayerfs/research/superdarn/usr/local/VTRST3.5-develop/include/superdarn/iqwrite.h:42:5: note: expected ‘unsigned int *’ but argument is of type ‘int *’
 int IQFwrite(FILE *fp,struct RadarParm *prm,
     ^
sim_real.c:258:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
   fscanf(fitfp,"-861128176  -856238336  166  6423104  6423104  19559904\n",&prm->time.yr,&prm->time.mo,&prm->time.dy,&prm->time.hr,&prm->time.mt,&prm->time.sc);
   ^
sim_real.c:260:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
   fscanf(fitfp,"-861128176  0.000000  -856238336  0.000000  196  6423104  0.000000  0.000000  0.000000  6423104\n",&cpid,&freq,&prm->bmnum,&noise_lev,&nave,&lagfr,&dt,&smsep,&rngsep,&nrang);
   ^
sim_real.c:370:4: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]

[ecbland]

We have the same problem on all four machines running RST at UNIS (all fresh installs done over the last 3 months). I didn't notice that this had happened until now because there was no "compilation aborted" message, and the functions we are using all work as expected. However, the problem is indeed evident in the log file in $RSTPATH/log/ and is the same as you describe above. The log files are also much larger than normal, and the log file size varies widely between successive compilations on the same machine (190MB - 1.3GB). I also noticed that a whole lot of whitespace(?) is printed in the terminal when sim_real is compiled.

[egthomas]

Hi Emma, I get the same 'whitespace' issue where the terminal goes absolutely crazy after it attempts to compile sim_real. Glad to hear I didn't do something stupid to my own machine.

[ksterne]

Last time we compiled it at VT (August 10th) it looks as though sim_real compiled without a problem. We're running Ubuntu 12.04, so maybe it's something with an updated c-compiler? It threw some of the same warnings though:

`Compiling Binary:/davit/lib/rst/rst//codebase/superdarn/src.bin/tk/tool/sim_real.1.0

make clean rm -f .o rm -f version.h rm -f errstr.h rm -f hlpstr.h rm -f sim_real make make.version /davit/lib/rst/VTRST3.5/codebase/superdarn/src.bin/tk/tool/sim_real.1.0 make.help cc -fPIC -Wall -O3 -ansi -D_GNU_SOURCE -D_LINUX -DSVGLIB -I/davit/lib/rst/rst//include/base -I/davit/lib/rst/rst//include/general -I/davit/lib/rst/rst//include/superdarn -c sim_real.c sim_real.c: In function ‘main’: sim_real.c:258:3: warning: format ‘-1299542064’ expects argument of type ‘int ’, but argument 3 has type ‘int16 ’ [-Wformat] sim_real.c:258:3: warning: format ‘-1299542064’ expects argument of type ‘int ’, but argument 4 has type ‘int16 ’ [-Wformat] sim_real.c:258:3: warning: format ‘-1299542064’ expects argument of type ‘int ’, but argument 5 has type ‘int16 ’ [-Wformat] sim_real.c:258:3: warning: format ‘-1299542064’ expects argument of type ‘int ’, but argument 6 has type ‘int16 ’ [-Wformat] sim_real.c:258:3: warning: format ‘-1299542064’ expects argument of type ‘int ’, but argument 7 has type ‘int16 ’ [-Wformat] sim_real.c:258:3: warning: format ‘-1299542064’ expects argument of type ‘int ’, but argument 8 has type ‘int16 ’ [-Wformat] sim_real.c:260:3: warning: format ‘-1299542064’ expects argument of type ‘int ’, but argument 5 has type ‘int16 ’ [-Wformat] sim_real.c:450:4: warning: pointer targets in passing argument 4 of ‘IQFwrite’ differ in signedness [-Wpointer-sign] /davit/lib/rst/rst//include/superdarn/iqwrite.h:42:5: note: expected ‘unsigned int ’ but argument is of type ‘int *’ sim_real.c:258:9: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result] sim_real.c:260:9: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result] sim_real.c:370:10: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result] mkdir -p /davit/lib/rst/rst//bin cc -L/davit/lib/rst/rst//lib -L/davit/lib/rst/rst//usr/lib -o /davit/lib/rst/rst//bin/sim_real sim_real.o -Wl,-Bstatic \ -lsim_data.1 -lradar.1 -lfitacf.1 -lraw.1 -lfit.1 -ldmap.1 -lrtime.1 -lrcnv.1 -lrmath.1 -liqdata.1 -Wl,-Bdynamic \ -lm -lz `

I don't see in your log dump which message it's having an error with. Is this compiling sim_real by itself or during the make.code process?

[ecbland]

It happens only during the make.code process. When I compile sim_real by itself there are no warnings, and no weird 'whitespace' appears in the terminal. I compiled the function by itself by running 'make sim_real' from the $RSTPATH/codebase/superdarn/src.bin/tk/tool/sim_real.1.0 directory. Is that the correct way to do it?

For the record, the 'whitespace' does show up in my log file after running make.code - hence the very large file size (hundreds of MB). Here's the relevant section of the log file - note where I have written "loads of whitespace :)

================================================================================
Compiling Binary:/usr/local/VTRST3.5/codebase/superdarn/src.bin/tk/tool/sim_real.1.0
================================================================================
make clean
rm -f *.o
rm -f version.h
rm -f errstr.h
rm -f hlpstr.h
rm -f sim_real
make
make.version /usr/local/VTRST3.5/codebase/superdarn/src.bin/tk/tool/sim_real.1.0
make.help
cc -fPIC -Wall -O3 -ansi -D_GNU_SOURCE -D_LINUX -D_SVGLIB_ -I/usr/local/VTRST3.5/include/base -I/usr/local/VTRST3.5/include/general -I/usr/local/VTRST3.5/include/superdarn -c sim_real.c    
sim_real.c: In function ‘main’:
sim_real.c:258:16: warning: format ‘-639886832’ expects argument of type ‘int *’, but argument 3 has type ‘int16 * {aka short int *}’ [-Wformat=]
   fscanf(fitfp,"-639886832  -634841344  167  6423104  6423104  34723024\n",&prm->time.yr,&prm->time.mo,&prm->time.dy,&prm->time.hr,&prm->time.mt,&prm->time.sc);
                ^
sim_real.c:258:16: warning: format ‘-639886832’ expects argument of type ‘int *’, but argument 4 has type ‘int16 * {aka short int *}’ [-Wformat=]
sim_real.c:258:16: warning: format ‘-639886832’ expects argument of type ‘int *’, but argument 5 has type ‘int16 * {aka short int *}’ [-Wformat=]
sim_real.c:258:16: warning: format ‘-639886832’ expects argument of type ‘int *’, but argument 6 has type ‘int16 * {aka short int *}’ [-Wformat=]
sim_real.c:258:16: warning: format ‘-639886832’ expects argument of type ‘int *’, but argument 7 has type ‘int16 * {aka short int *}’ [-Wformat=]
sim_real.c:258:16: warning: format ‘-639886832’ expects argument of type ‘int *’, but argument 8 has type ‘int16 * {aka short int *}’ [-Wformat=]
sim_real.c:260:16: warning: format ‘-639886832’ expects argument of type ‘int *’, but argument 5 has type ‘int16 * {aka short int *}’ [-Wformat=]
   fscanf(fitfp,"-639886832  0.000000  -634841344  0.000000  196  6423104  0.000000  0.000000  0.000000  6423104\n",&cpid,&freq,&prm->bmnum,&noise_lev,&nave,&lagfr,&dt,&smsep,&rngsep,&nrang);
                ^
sim_real.c:450:27: warning: pointer targets in passing argument 4 of ‘IQFwrite’ differ in signedness [-Wpointer-sign]
    IQFwrite(stdout,prm,iq,badtr,samples);
                           ^
In file included from sim_real.c:48:0:
/usr/local/VTRST3.5/include/superdarn/iqwrite.h:42:5: note: expected ‘unsigned int *’ but argument is of type ‘int *’
 int IQFwrite(FILE *fp,struct RadarParm *prm,
     ^
sim_real.c:258:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
   fscanf(fitfp,"-639886832  -634841344  167  6423104  6423104  34723024\n",&prm->time.yr,&prm->time.mo,&prm->time.dy,&prm->time.hr,&prm->time.mt,&prm->time.sc);
   ^
sim_real.c:260:3: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
   fscanf(fitfp,"-639886832  0.000000  -634841344  0.000000  196  6423104  0.000000  0.000000  0.000000  6423104\n",&cpid,&freq,&prm->bmnum,&noise_lev,&nave,&lagfr,&dt,&smsep,&rngsep,&nrang);
   ^
sim_real.c:370:4: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result]
    fscanf(fitfp,"-634841344

**[LOADS OF WHITESPACE]**

64244224  1601447561  0.000000  0.000000  0.000000\n",&qflg[i],&v_dop,&amp0,&t_d);
    ^
mkdir -p /usr/local/VTRST3.5/bin
cc -L/usr/local/VTRST3.5/lib -L/usr/local/VTRST3.5/usr/lib -o /usr/local/VTRST3.5/bin/sim_real sim_real.o -Wl,-Bstatic \
                           -lsim_data.1 -lradar.1 -lfitacf.1 -lraw.1 -lfit.1 -ldmap.1 -lrtime.1 -lrcnv.1 -lrmath.1 -liqdata.1  -Wl,-Bdynamic \
                           -lm -lz   
================================================================================
Compiling Binary:/usr/local/VTRST3.5/codebase/superdarn/src.bin/tk/tool/test_cfit.1.6
================================================================================
make clean

[kkotyk]

What versions of glibc and gcc is everyone using?

[ecbland]

gcc version 5.4.0 glibc version 2.23

[egthomas]

gcc version 5.4.0 glibc version 2.23 (same as Emma)

our IT department required us to upgrade everything to Ubuntu 16.04.1 LTS within the last 2 months

[ksterne]

gcc:

4.6.3 or gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 for completeness

glibc:

Maintainer: Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com Original-Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org Architecture: amd64 Source: eglibc Version: 2.15-0ubuntu10.15

Seems like I'm a few versions behind @ecbland and @egthomas. OS is still Ubuntu 12.04....thanks for the heads up guys on holding off on updating to U'16.

[egthomas]

Ok, so I've been working my way through the installation issues today and have come up with a list of the "bare minimum" steps necessary to make it at least to the compilation failure on sim_real. Starting with a fresh copy of VTRST3.5 from github, here are the fixes in the order in which their associated compilation errors appear (where 'rst' is your generic VTRST3.5 directory):

1. Add mkdir -p ${LIBPATH} to line 161 of make.code in rst/build/script (need to create "lib" directory before Kevin's cmpfit patch tries copying files there)
2. Copy cdf.h to rst/codebase/analysis/src.lib/cdf/rcdf.1.5/include
3. Copy idl_export.h to rst/include/superdarn
4. Change CDF_PATH in base.bash (or base.tcsh) in rst/.profile

If I tar the rst/codebase/superdarn/src.bin/tk/tool/sim_real.1.0 directory such that compilation bypasses that particular function then one last step is necessary:

5) Copy idl_export.h to rst/include/analysis

And finally it looks like compilation succeeds. I think the modification to make.code in step 1 is appropriate for a pull request but I guess the cdf.h and idl_export.h files are generally user-dependent. It also looks like there is a typo in rst/build/rpkg/rst.3.5/build.txt on line 20 (line should be deleted) but I don't know if that is causing any problems. Should we go ahead and tar the sim_real directory so users can actually compile this thing? It doesn't seem like anyone wants to troubleshoot AJ's code.

[ecbland]

I agree that adding mkdir -p lib to make.code is an appropriate pull request. I've always wondered why I had to create that directory manually.

After I tar the sim_real.1.0 directory (and using the earlier versions of filter.c and make_grid.c) I am able to compile RST without any problems.

Step 3 was not necessary for me: so long as $IDL_IPATH is set correctly in rst/.profile/idl.bash then RST is able to find idl_export.h there. Note that $IDL_IPATH is set to /usr/local/itt/idl/external/include by default but I don't think that's the default installdir for IDL anymore (mine is /usr/local/exelis/...)

[egthomas]

Good catch - properly setting $IDL_IPATH in rst/.profile/idl.bash takes care of steps 3 and 5 in my previous list. So a revised set of instructions would look something like

1. Add mkdir -p ${LIBPATH} to line 161 of make.code in rst/build/script
2. Copy cdf.h to rst/codebase/analysis/src.lib/cdf/rcdf.1.5/include
3. Change $IDL_IPATH in rst/.profile/idl.bash (or rst/.profile/idl.tcsh)
4. Change $CDF_PATH in rst/.profile/base.bash (or rst/.profile/base.tcsh)

I can submit a pull request for the modification to make.code but I want to try looking at the dlm issues in #15 first (also waiting for the pull request to fix my typos in filter.c and make_grid.c to be approved).

*Edit - do people still need to edit the $NETCDF_PATH or perform the Copy the libcdf.a and libcdf.so into ~/VTRST3.5/lib/ step listed in the readme?

[ecbland]

Ok, I can compile RST without copying libcdf.a and libcdf.so to ~/VTRST3.5/lib. Never tried that before. I can also compile the software with $NETCDF_PATH set to a directory that doesn't exist. I haven't checked whether omitting these files/paths affects the functionality of the software in any way.

Regarding change (1) above, issue #9 looks relevant.

And while we're here, perhaps we should also change the hard-coded directory structures in /rst/.profile/superdarn.bash:

• change export SD_HDWPATH="/davit/lib/tables/superdarn/hdw/" to export SD_HDWPATH="${RSTPATH}/tables/superdarn/hdw/".
• change export SD_RADAR="/davit/lib/tables/superdarn/radar.dat" to export SD_RADAR="${RSTPATH}/tables/superdarn/radar.dat"

[egthomas]

Fully agreed on change (1) that it pertains to #9, and I may have also mentioned changing those hard-coded directory paths in one of my previous comments on that issue.

[ksterne]

Are we still considering just tarring the sim_real package here? I'm for it as the alternative may be to remove it. If we do this, should we add getting this package to compile as a "to-do" in the README.md file?

[pasha-ponomarenko]

Hi guys,

sim_real.c is some sort of a wrapper for the simulator, sim_data.c, and it is supposed to reproduce "real" range-time distribution of data. I don't think anyone uses it (I don't!) so it can be safely tar'ed or temporarily removed.

Cheers,

Pasha

---

From: Kevin Sterne notifications@github.com Sent: 17 November 2016 15:18 To: vtsuperdarn/VTRST3.5 Subject: Re: [vtsuperdarn/VTRST3.5] compiling failing at sim_real.1.0 (#19)

Are we still considering just tarring the sim_real package here? I'm for it as the alternative may be to remove it. If we do this, should we add getting this package to compile as a "to-do" in the README.md file?

You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/vtsuperdarn/VTRST3.5/issues/19#issuecomment-261372454, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AFEZyPoDmBfdn9ECmw_E9jYReiRpwLxuks5q_MS2gaJpZM4KHwOh.