The linking lines for IPP have changed between versions. What we have put by default in the setup.bash and setup.csh files is appropriate for the latest IPP versions. If compilation of any DiFX components fails complaining about any IPP libraries, edit setup.[bash/csh] and try uncommenting/changing the IPPLIB32/64 lines as directed by the inline comments.
If this doesn't fix the problem, please note the error message and try to fix the lines in setup.[bash/csh] appropriately. Once you have fixed the problem (or given up in confusion) please email difx-users and let us know.
Probably DIFX is configured to send all log messages via muticast broadcast but you do not have any program running to capture the messages. Either disable muticast logging in DIFXIO but unseting the enviroment variables DIFX_MESSAGE_GROUP, DIFX_MESSAGE_PORT, DIFX_BINARY_GROUP and DIFX_BINARY_PORT. These are probably set in setup.csh or setup.bash. Alternatively run
Which will capture and display the error messages
DiFX runs and gives errors such as
error while loading shared libraries: libmark5access.so.0: cannot open shared object file: No such file or directory
You have a problem with your unix setup, probably setting up the environment on remote hosts. One the machine you are running difx from try
The output should be something like
linux-vdso.so.1 => (0x00007fffaeffe000) libmark5access.so.0 => /home/vlbi/difx/lib/libmark5access.so.0 (0x00007f34a6a0c000) libippsem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippsem64t.so.6.0 (0x00007f34a6cf1000) libguide.so => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libguide.so (0x00007f34a68a4000) libippvmem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippvmem64t.so.6.0 (0x00007f34a678d000) libiomp5.so => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libiomp5.so (0x00007f34a6620000) libippcoreem64t.so.6.0 => /opt/intel/ipp/6.0.2.076/em64t/sharedlib/libippcoreem64t.so.6.0 (0x00007f34a6514000) libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007f34a6239000) libdifxmessage.so.0 => /home/vlbi/difx/lib/libdifxmessage.so.0 (0x00007f34a6031000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f34a5e15000) librt.so.1 => /lib/librt.so.1 (0x00007f34a5c0c000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f34a5900000) libm.so.6 => /lib/libm.so.6 (0x00007f34a567d000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f34a5466000) libc.so.6 => /lib/libc.so.6 (0x00007f34a5113000) libdl.so.2 => /lib/libdl.so.2 (0x00007f34a4f0f000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f34a4ce6000) /lib64/ld-linux-x86-64.so.2 (0x00007f34a6c50000)
If any libraries say “not found” you probably have to fix your LD_LIBRARY_PATH.
If this works try some of the following to track down where the problem is. The exact commands you run will depend on your specific setup (e.g. rsh vs ssh, path to mpifxcorr)
Within the difx project many source files are endowed with comment lines that get updated when files are checked out to reflect version and date information. Python, by default, expects only 7-bit ASCII characters (hence no accented or otherwise non-American characters) even in comments. A problem can happen in cases such as checking out a file in a Spanish locale with a Saturday date being added to the comment field. The error message in this instance would be:
SyntaxError: Non-ASCII character '\xe1' in file program.py on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
Quick fix Edit the file in question (e.g., program.py), simply removing the line of text referenced in the error message (assuming this is a comment line)
Long term fix Being investigated…
If an RPC error is encountered when starting the
calcserver program, it is possible that the
portmap service is either not installed or not running. Please consult your OS distribution documentation for rectifying this. In the case of Debian or Ubuntu Linux, the solution may be as simple as:
apt-get install portmap