[wsjt-devel] cmake errors in 1.7.0 r6272

[Josh Rovero]

Checked out revision 6272
...
...
...
-- Configuring done
CMake Error at CMakeLists.txt:930 (add_executable):
Cannot find source file:

lib/init_random_seed.c

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx


CMake Error at CMakeLists.txt:887 (add_library):
Cannot find source file:

lib/init_random_seed.f90

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx


CMake Error: Cannot determine link language for target "wsjt_cxx".
CMake Error: CMake can not determine linker language for target: wsjt_cxx
CMake Error: Cannot determine link language for target "wsjt_fort".
CMake Error: CMake can not determine linker language for target: wsjt_fort
CMake Error: Cannot determine link language for target "wsjt_fort_omp".
CMake Error: CMake can not determine linker language for target:
wsjt_fort_omp
CMake Error: CMake can not determine linker language for target: wsprd
CMake Error: Cannot determine link language for target "wsprd".
-- Generating done

[Bill Somerville]

Post by Josh Rovero
lib/init_random_seed.c
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx
lib/init_random_seed.f90
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

Hi All,

sorry about that, I shouldn't rush to finish a commit when I'm late to
be somewhere else.

Should be OK now.

73
Bill
G4WJS.

------------------------------------------------------------------------------

[KI7MT]

Hi Bill,

Not sure what I'm doing wrong here, but I am getting the same or similar
error on Linux, after the update, when trying to run the Makefile
directly in:

^/wsjtx/lib/wsprd


-----
gcc -I/usr/include -Wall -Wno-missing-braces -O3 -ffast-math -c wsprd.c
wsprd.c:43:34: fatal error: lib/init_random_seed.h: No such file or
directory
#include "lib/init_random_seed.h"
-----

73's
Greg, KI7MT

Post by Bill Somerville

Post by Josh Rovero
lib/init_random_seed.c
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx
lib/init_random_seed.f90
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

Hi All,
sorry about that, I shouldn't rush to finish a commit when I'm late to
be somewhere else.
Should be OK now.
73
Bill
G4WJS.
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

------------------------------------------------------------------------------

[Bill Somerville]

Post by KI7MT
Not sure what I'm doing wrong here, but I am getting the same or similar
error on Linux, after the update, when trying to run the Makefile
^/wsjtx/lib/wsprd

Hi Greg,

my changes are with the intent of making custom non-portable makefiles
redundant.

You can use the CMake generated makefiles to build wsprd like:

cmake --build <build-tree-root> --target wsprd

73
Bill
G4WJS.

------------------------------------------------------------------------------

[Steven Franke]

Post by Bill Somerville
cmake --build <build-tree-root> --target wsprd

Bill - this approach does enable me to build jt65sim, however it does not install the re-built jt65sim in the install directory - I am now copying it over to the install directory manually. Is there a better way?

Also, just fyi - no action required, jt65sim is not working with the new init_random_seed routine. I think that it’s because Joe’s gran actually calls the C random number generator, not the Fortran one. I will try to sort that out this evening.

Thanks for your help on this.
Steve k9an



------------------------------------------------------------------------------

[Bill Somerville]

Post by Steven Franke

Post by Bill Somerville
cmake --build <build-tree-root> --target wsprd

Bill - this approach does enable me to build jt65sim, however it does not install the re-built jt65sim in the install directory - I am now copying it over to the install directory manually. Is there a better way?
Also, just fyi - no action required, jt65sim is not working with the new init_random_seed routine. I think that it’s because Joe’s gran actually calls the C random number generator, not the Fortran one. I will try to sort that out this evening.
Thanks for your help on this.
Steve k9an

Hi Steve,

the non-installation of the *sim tools was deliberate, if they are
intended to be in the final package then they can be installed. The
constraint, which is not negotiable because of the way CMake does
packaging, is that if it gets install then it gets packaged.

I thought I had got the jt65sim initialization on the RNGs right. There
are initializing functions for both C and Fortran since the two language
PRNGs are distinct. It looks like the Fortran function sgran needs to be
called at the start of jt65sim as that now calls the new C function
init_random_seed(). I'm not sure if the Fortran gran() function is
called by anything that jt65sim uses but TBH it doesn't rally matter if
jt65sim calls both the Fortran init_random_seed subroutine *and* the
Fortran gran seed function sgran. I have made that change, let me know
if that sorts things out.

73
Bill
G4WJS.

------------------------------------------------------------------------------

[Steven Franke]

Hi Bill and Joe -

As it turns out, the random number stuff in jt65sim is a bit confusing.

For the Gaussian random noise that is used to set the SNR for simulated data we call the C routine gran.c which, in turn, calls the C random number generator rand().

For the random envelope simulation (the Rayleigh fading) we use the Fortran intrinsic routine “random_number()”.

So, to ensure that we get a unique set of random numbers for both the noise and the fading, I think that we’d need to call both the C and Fortran versions of init_random_seed. Since we have two different routines with the same name (init_random_seed.f90 and init_random_seed.c), I am confused about how to do this…

For the record - what is happening currently is that the Gaussian random noise is the same for every invocation of jt65sim, but when fspread is nonzero the Rayleigh fading function is different each time the program is run.

Steve k9an
------------------------------------------------------------------------------

[Bill Somerville]

Post by Steven Franke
Hi Bill and Joe -

Hi Steve,

Post by Steven Franke
As it turns out, the random number stuff in jt65sim is a bit confusing.

Agreed!

Post by Steven Franke
For the Gaussian random noise that is used to set the SNR for simulated data we call the C routine gran.c which, in turn, calls the C random number generator rand().
For the random envelope simulation (the Rayleigh fading) we use the Fortran intrinsic routine “random_number()”.
So, to ensure that we get a unique set of random numbers for both the noise and the fading, I think that we’d need to call both the C and Fortran versions of init_random_seed. Since we have two different routines with the same name (init_random_seed.f90 and init_random_seed.c), I am confused about how to do this…

That's no problem. I have changed the C wrapper sgran_() to do the C
library PRNG seeding so where gran() is used in Fortran the main routine
of the program should call sgran to seed the C library PRNG.

Post by Steven Franke
For the record - what is happening currently is that the Gaussian random noise is the same for every invocation of jt65sim, but when fspread is nonzero the Rayleigh fading function is different each time the program is run.

That is because sgran was not being called, should be OK now.

Post by Steven Franke
Steve k9an

73
Bill
G4WJS.

------------------------------------------------------------------------------

[Steven Franke]

Post by Bill Somerville

Post by Steven Franke
For the record - what is happening currently is that the Gaussian random noise is the same for every invocation of jt65sim, but when fspread is nonzero the Rayleigh fading function is different each time the program is run.

That is because sgran was not being called, should be OK now.

Yep, it appears to work fine now. Thanks!
Steve k9an


------------------------------------------------------------------------------

[Steven Franke]

Alas, I’m getting some significantly different results for Rayleigh fading cases now, so it may be that something is not yet right. Or, perhaps something was not right before. Either way, it will take some time to track down. I will report back when I get it figured out.
Steve k9an

Post by Steven Franke

Post by Bill Somerville

Post by Steven Franke
For the record - what is happening currently is that the Gaussian random noise is the same for every invocation of jt65sim, but when fspread is nonzero the Rayleigh fading function is different each time the program is run.

That is because sgran was not being called, should be OK now.

Yep, it appears to work fine now. Thanks!
Steve k9an
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

------------------------------------------------------------------------------

[Bill Somerville]

Post by Steven Franke
Alas, I’m getting some significantly different results for Rayleigh fading cases now, so it may be that something is not yet right. Or, perhaps something was not right before. Either way, it will take some time to track down. I will report back when I get it figured out.

Hi Steve, Joe and All,

I have made some changes to jt65sim's command line parsing. Apologies if
you have scripts that drive this tool but the changes required should be
small. Use 'jt65sim -h' for details. I have added a '-p' switch which
disables all PRNG seeding so that absolutely repeatable simulations may
be run if required. I have also added some sensible, to me at least,
default argument values.

I have also added building of jt65 to the CMake build script since I'm
sure it is in use at present with all the work on JT65 decoding.

Further to a comment by Steve in a previous message; when you build
targets with the CMake generated makefiles, you can usually run or debug
those targets directly in the build tree. There's no need to install oir
manually move the executables to an install directory. The programs
wsjtx and jt9 are exceptions to this rule since they need some other
infrastructure that is only created by installing them. I will try and
remove this last constraint as I believe that is now possible with the
better control of writeable locations and not having to communicate with
KVASD any more.

With respect to Steve's issue above, I think that the only difference is
that before my changes the Fortran RANDOM_NUMBER PRNG was not being
seeded whereas now it is. Could this be the source of the differences
you are seeing? If so the new '-p' switch on jt65sim may be helpful in
diagnosing this issue.

73
Bill
G4WJS.

------------------------------------------------------------------------------

[Greg Beam]

Hi Bill,

OK. I wasn't aware this change (using cmake v.s. the Makefile) was
coming, so, for the time being, the build script in JTSDK-Nix will
remain broken as I wont be able to work on this for most of this week.

73's
Greg, KI7MT

Post by Bill Somerville

Post by KI7MT
Not sure what I'm doing wrong here, but I am getting the same or similar
error on Linux, after the update, when trying to run the Makefile
^/wsjtx/lib/wsprd

Hi Greg,
my changes are with the intent of making custom non-portable makefiles
redundant.
cmake --build <build-tree-root> --target wsprd
73
Bill
G4WJS.
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

------------------------------------------------------------------------------

[Bill Somerville]

Post by Greg Beam
OK. I wasn't aware this change (using cmake v.s. the Makefile) was
coming, so, for the time being, the build script in JTSDK-Nix will
remain broken as I wont be able to work on this for most of this week.

Hi Greg,

I am adverse to non-DRY (Don't Repeat Yourself) ways of building things,
the CMake build script should be able to build everything that is in the
public domain. No problem with developers having their own private
makefiles etc but if they get checked in there is a maintenance hazard
and they are rarely portable across the platforms we support.

There are occasional complications, for example I queried Steve K9AN
about a Makefile he was publishing and it turns out the real problem was
to do with random number generation and once that is sorted out the
CMake script does the job just fine.

73
Bill
G4WJS.

------------------------------------------------------------------------------

[Steven Franke]

Hi Bill,

I'm not able to consistently get different Gaussian sky-noise realizations on successive runs of jt65sim in my frame-error-rate script. The symptoms are strange, and it took me a while to figure out what’s going on. I get a string of unique seeds on some runs of the frame-error-rate script, but on others I get groups of two or sometimes a long string of identical seeds in a row.

Turns out that the C routine, init_random_seed(), is (for some reason) not reading from /dev/urandom anymore (at least on my OS X laptop) and is falling back to time(NULL)^getpid(). This fails in my case because I happen to be calling the routine about once per second, in which case time and getpid increase in lock-step such that the bitwise XOR of time(NULL) and getpid() doesn’t always change between successive calls. For example, consider the time and getpid on these successive runs of the init_random_c test program:

time 1450406520 getpid 65606
time 1450406521 getpid 65607

The value of time^getpid is the same for these successive sets of values, so the seed is the same. If you hit it just right (and happen to be calling the program approximately once per second) you can get long strings where the seed never changes.

It seems like adding or multiplying the time and getpid might be safer.

Steve k9an


------------------------------------------------------------------------------

[Bill Somerville]

Post by Steven Franke
This fails in my case because I happen to be calling the routine about once per second, in which case time and getpid increase in lock-step

Hi Steve,

that's a good one!

I have fixed the problem of not using /dev/urandom.

I'll have a think about a better way of generating entropy for the seed
without /dev/urandom.

Sorry you had to get so deep into it to discover this :( just proves how
difficult is to make a good PRNG I suppose.

73
Bill
G4WJS.

------------------------------------------------------------------------------