HEASoft v6.28 - Known Issues

If you are using HEASoft v6.27.x and don't want to upgrade to v6.28 just yet, see the HEASoft 6.27.x Issues List.

Several packages track issues separately from this page:

• Swift
• CALDB
• XSPEC
• XSTAR
• XIMAGE
• XRONOS

The following is a list of known issues in v6.28 of HEASoft not covered by the above pages.

• makefilter & g++ 11.x:
  
  The task makefilter (attitude package) may fail to build with newer g++ that enforce the C++17 standard. A fix for this was applied to downloads in 2021 May, but older source code downloads will need a patch:

    1) Download the new makefilter patch and unpack it in this directory:
  
       heasoft-6.28/attitude/tasks/newmakefilter/
  
    2) Restart the HEASoft build in heasoft-6.28/BUILD_DIR using "make".
  

• nuflagbad "buffer overflow detected":
  
  Some users of the Ubuntu Linux OS 20.04 (and newer) have reported a run-time buffer overflow error in some NuSTARDAS tasks (e.g. nuflagbad). The problem is tied to the max value of the system PID, which changed from 32768 in older Ubuntu to a larger number in 20.04. This issue will be fixed in HEASoft 6.29 (coming soon), but until then a temporary work around is to set the maximum PID to a lower value, e.g. to the older value of 32768 using the following:

    sudo sysctl -w kernel.pid_max=32768
  

• Apple Silicon (ARM/M1):
  
  We are now able to support builds of HEASoft on new Mac hardware using Homebrew or MacPorts compilers installed through the Rosetta 2 Intel binary translation. The method is described here for Homebrew but an analogous approach can be used for MacPorts:

  1) Make sure Rosetta is installed:

    $ sudo softwareupdate --install-rosetta
  

  2) Install XQuartz version 2.7.11, which is Intel architecture.

  3) Install Homebrew, prefacing the curl command with the Rosetta Intel prefix "arch -x86_64", for example:

    $ arch -x86_64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
  

  4) Install the Homebrew packages gcc, perl and python using the same Rosetta Intel prefix (this assumes you used the default Homebrew install location of /usr/local):

    $ arch -x86_64 /usr/local/bin/brew install gcc
    $ arch -x86_64 /usr/local/bin/brew install perl
    $ arch -x86_64 /usr/local/bin/brew install python
  

  5) Download the HEASoft 6.28 source code (if you don't already have it), and unpack the tar file:

    $ tar zxf heasoft-6.28src.tar.gz
  

  6) Download this configuration patch and unpack it on top of the 6.28 source code:

    $ tar zxf heasoft-6.28src_arm64_patch.tar.gz
  

  7) Set compiler variables (this again assumes you used the default Homebrew install location of /usr/local):

   In C-shell variants (tcsh/csh):           In Bourne shell variants (bash/sh/zsh):
  
    $ setenv CC /usr/local/bin/gcc-11         $ export CC=/usr/local/bin/gcc-11
    $ setenv CXX /usr/local/bin/g++-11        $ export CXX=/usr/local/bin/g++-11
    $ setenv FC /usr/local/bin/gfortran-11    $ export FC=/usr/local/bin/gfortran-11
    $ setenv PERL /usr/local/bin/perl         $ export PERL=/usr/local/bin/perl
    $ setenv PYTHON /usr/local/bin/python3    $ export PYTHON=/usr/local/bin/python3
  

  8) Before proceeding with the build, note that you should either remove /opt/local/bin from your PATH or use the "--without-lynx" configure option to avoid configuration errors in the "lynx" package. Then, configure and build heasoft as usual, i.e.:

    $ cd heasoft-6.28/BUILD_DIR
    $ ./configure
    $ make
    $ make install
  

• macOS 11 Big Sur (Intel):
  
  We do now support builds of HEASoft source code on macOS 11 "Big Sur" (Intel architecture) when using the latest Homebrew GCC 10.2 compilers, specifically version 10.2.0_3 or newer. Installations done using older Homebrew GCC 10.2 (10.2.0_2 or older) may suffer a run-time "abort" in Xspec and are therefore not supported.

  The MacPorts GCC 10.2 compiler suite is also supported, though at least one run-time problem is known, a failure in ximage when trying to use the /XTK graphical device.

• Apple XCode 12:
  
  Builds of HEASoft using Apple XCode 12 compilers are not supported, though we hope to be able to support them in a future release. Users are advised to follow the instructions in our Mac installation guide for using third-party compilers (Homebrew, MacPorts, etc.) instead.
• Mac "C compiler cannot create executables":

  The HEASoft configure script may fail with "C compiler cannot create executables", and one of the config.logs may show
  
  ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd' for architecture x86_64
  
  Users have reported that putting /usr/bin at the front of your PATH environment variable (as recommended in our Mac installation guide) may resolve this problem.
  
  This problem may also occur if your compiler suite (e.g. Homebrew or MacPorts) is out-of-synch with the Apple XCode Command Line Tools, for example as described here. In a scenario where the version 12 Command Line Tools were installed, users have reported success getting around this by removing them and re-installing e.g. the 11.5 version.
  
  

• rbnrmf & xisresp (Suzaku):
  
  The Suzaku script xisresp is broken due to a bug in the task rbnrmf (itself a wrapper to ftrbnrmf) which misses the case of 'binfile' being set to a filename with 'cmpmode' not set. To fix your source code distribution, do the following:

    1) Download the new rbnrmf and copy it into
  
       heasoft-6.28/heasptools/ftrbnrmf/
  
    2) Initialize HEASoft, then re-install rbnrmf:
  
       $ cd heasoft-6.28/heasptools/ftrbnrmf/
       $ hmake install
  

• XSTAR 2.54c:
  
  A bug in xstar (in phint53) has been fixed to avoid negative opacities. To patch your existing HEASoft 6.28 source code distribution, do the following:

    1) Download the 2.54c patch file and unpack it on top of your heasoft-6.28 directory.  It contains:
  
       heasoft-6.28/ftools/xstar/src/xstar/xstar.f90
       heasoft-6.28/ftools/xstar/xstarlib/src/fheader.f90
       heasoft-6.28/ftools/xstar/xstarlib/src/phint53.f90
       heasoft-6.28/ftools/xstar/xstarlib/src/xstarsetup.f90
  
    2) Initialize HEASoft, then rebuild and re-install xstar:
  
       $ cd heasoft-6.28/ftools/xstar
       $ hmake clean
       $ hmake all
       $ hmake install
  

• "Unidentified Developer" error on Macs:
  
  Some Mac users have reported problems configuring and/or running pre-compiled HEASoft binaries. To free HEASoft binaries from the Apple quarantine, use the xattr utility, e.g.:

  $ cd heasoft-6.28/x86_64-apple-darwin-19.6.0
  $ xattr -r -d com.apple.quarantine BUILD_DIR/configure lib/* bin/*
  

• FV and Fedora Linux:
  
  The FV (FITSViewer) GUI suffers a memory fault when built on the Fedora Linux OS. We are investigating and hope to have a solution soon.
• Fortran compiler requirements:
  
  HEASoft now includes a new dependency on the FGSL library which requires a Fortran 2008 feature (c_loc for targeted arrays); therefore GNU Fortran compilers older than version ~5.x are unsupported.
• Apple Xcode 11.x:
  
  Users who have updated their Xcode to 11.x may see errors when configuring HEASoft ("failed to link program... WARNING: Configure failed in the AST package!" which refers to the specific error "ld: library not found for -lSystem" as seen in the heacore/ast/config.log) with a compiler setup that includes the Xcode clang/clang++ (gcc/g++) plus a MacPorts Fortran compiler. Two possible workarounds are available:
  
  1) For e.g. OS 10.14 (Mojave), follow a recommendation from the MacPorts bug tracker and create a symbolic link for the MacOS10.14.sdk, then continue using MacPorts as needed:

      % cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
      % sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk
  

  2) Use only the HomeBrew compilers (which do not appear to suffer from this issue), e.g.

      % setenv CC /usr/local/bin/gcc-9       % export CC=/usr/local/bin/gcc-9
      % setenv CXX /usr/local/bin/g++-9      % export CXX=/usr/local/bin/g++-9
      % setenv FC /usr/local/bin/gfortran-9  % export FC=/usr/local/bin/gfortran-9
  

• XIMAGE and gfortran 8.x (or newer) on macOS:
  
  When built with the Apple XCode C compiler (clang) paired with gfortran newer than version 8.0, ximage may generate "Invalid header key" messages and a Tcl error "Failed to run tcl: pgtk::upcopy MAP1 MAP9". Subsequent attempts to display the image may then result in a segmentation fault. Note that this problem will affect tasks that use ximage such as xrtpipeline or nupipeline. To get around this, we recommend avoiding the Apple XCode compilers and using only a third-party compiler suite instead, as noted in our Mac installation guide.


• Perl symbol lookup error, "undefined symbol: Perl_Gthr_key_ptr":

  If running a HEASoft Perl script generates an error similar to the above, it may result from a Perl version incompatibility (common when using the pre-compiled binaries), but it may also occur if you have the VERSIONER_PERL_PREFER_32_BIT environment variable set to "yes". If "echo VERSIONER_PERL_PREFER_32_BIT" returns "yes", then unset it:

     unset VERSIONER_PERL_PREFER_32_BIT
  
  or, in C-shell:
  
     unsetenv VERSIONER_PERL_PREFER_32_BIT
  

• Mac "configure failed..." Fortran compiler issue:

  The configure script may generate an error ("Configure failed in the AST package!", or "configure failed for heacore component fftw!") resulting from a MacPorts assembler (as) under /opt/local/bin being ahead of the default Apple /usr/bin/as in a user's PATH (which may result from an automated change made to .profile during a MacPorts installation). To get past this issue, put /usr/bin at the front of your PATH:

     export PATH="/usr/bin:$PATH"
  

• MacPorts "unexpected token" linker issue:

  If you are using MacPorts compilers in your build, 'make' may fail when building the HEASoft source code distribution with an error referring to a new Xcode linker ("ld") format ("tbd"), e.g.:

  ld: in '/System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji.tbd', unexpected token: !tapi-tbd-v2 ...
  

  The underlying issue is discussed here and here; it appears that when new versions of the XCode command line tools are released, problems such as this may affect MacPorts compilers until they catch up with Apple's changes. Users should be able to get around the error in our build by installing the MacPorts 'xcode' variant of the linker ld64 as a temporary measure:

  
      sudo port install ld64 +ld64_xcode
  
  

  and when MacPorts eventually supports the latest XCode command line tools, you can switch back to the latest ld64 with the following:

  
      sudo port install ld64 +ld64_latest
  
  

• Mac "suffix or operands invalid for 'movq'" Fortran compiler issue:

  When using the gnu.org gfortran binaries note their recommendation that when installing new versions of the compiler you should remove the previous gfortran installation first:

     $ sudo rm -r /usr/local/gfortran /usr/local/bin/gfortran
  

  Failure to do so may result in a corrupted compiler installation, leading to the "suffix or operands invalid for 'movq'" error.



• Ubuntu ds9 & HEASoft:

  After initializing HEASoft on Ubuntu Linux, the ds9 GUI (if installed) may fail to start up (mentioning "can't find package xml", "can't find package uri 1.1", or "package require base64""). This results from incompatibilities between the Tcl/Tk included with HEASoft and the Ubuntu system libraries. Until a more elegant solution can be devised, we recommend that users try one of the following options, depending on the file type of your ds9 (shell script or compiled executable - check the output from "file `which ds9`" to determine which it is):

  
  1) If ds9 is the shell script version, edit it to change the line
  
       exec wish8.6 -f ${DS9_HOME-/usr/share/saods9}/library/ds9.tcl $*
  
     to
  
       exec /usr/bin/env -u LD_LIBRARY_PATH /usr/bin/wish8.6 -f ${DS9_HOME-/usr/share/saods9}/library/ds9.tcl $*
  
  or
  
  2) If ds9 is the compiled executable version, create a new file
     "$HEADAS/bin/ds9" containing the following lines:
  
       #!/bin/sh
       exec /usr/bin/env -u LD_LIBRARY_PATH /usr/bin/ds9 "$@"
  
     (Note this assumes that `which ds9` = /usr/bin/ds9)
  
     To make the new script executable, run the following command:
  
       $ chmod +x $HEADAS/bin/ds9
  
     Then, as long as $HEADAS/bin is ahead of /usr/bin in your PATH, you
     should now be able to successfully run ds9 from the command line:
  
       $ rehash
       $ ds9
  
  




• "relocation R_X86_64_32 against `.rodata' can not be used when making a shared object":
  
  Users building HEASoft from the source code distribution may run into this error which refers to a "Bad value" in the file heacore/wcslib/C/cel.o, from which the linker "could not read symbols". It also suggests that you "recompile with -fPIC". This situation most likely occurrs when users perform a re-build after a previously unsuccessful build attempt. To get past this issue, try the following:

  
     $ cd heasoft-6.27.1/BUILD_DIR
     $ make distclean
  
  

  When that finishes, restart the build procedure beginning with "./configure", then "make", and let us know if this does not resolve the problem.



• fv - XPA_METHOD:
  
  Some users of the fv GUI may experience long delays at startup, or error messages of the type "XPA$WARNING: xpans needs to be running on this machine", or "XPA$ERROR: invalid host name specified: $host:$port" (when using the ds9 display device). These issues tend to occur on Macs with customized firewall settings, or on machines without valid IP addresses. This can be resolved by setting the XPA_METHOD environment variable to the value "local" (to use local/UNIX sockets instead of inet sockets):

  
          export XPA_METHOD=local          # Bourne shell (bash/sh)
  or
          setenv XPA_METHOD local          # C-shell (csh/tcsh)
  
  

• Perl version mismatch::
  
  Pre-compiled Perl libraries used extensively by mission software (Swift, Suzaku, NuSTAR) and other packages are not especially portable, so we generally recommend building HEASoft from the source code distribution.



• xspec / PLT - wenv, whead, wdata:
  
  Some GNU Fortran compilers (gfortran 4.4.x, 4.0.x, 4.1.x) appear to have internal issues which prevent the PLT commands wenv, whead and wdata from working unless an output file is specified; i.e. attempts at producing terminal output may fail with "Fortran runtime error: Invalid argument". To get around this, provide an output file name when using these commands, for example:

       wenv myFile1.qdp
       whead myFile2.qdp
       wdata myFile3.qdp
  




• HEASoft and other software packages (CIAO, XMM-SAS):
  
  

  Please note:

  Users may wish to download and run our hwrap script to create an alternate runtime environment for HEASoft to help avoid conflicts with other software packages, but if not, please take note of the potential pitfalls below:
  
  
  • CIAO:
    
    Please see the following notes at the CXC website regarding the potential dangers of using CIAO and HEASoft together in the same session:
    
    
    • FTOOLS & CIAO
      
  
  
  
  • XMM-SAS:
    
    The XMM-SAS setup typically adjusts your LD_LIBRARY_PATH environment variable (or DYLD_LIBRARY_PATH on macOS) to include the SAS library folders, one of which includes a copy of the C++ compiler library (libstdc++). This can cause problems building HEASoft, so we recommend that HEASoft be built in a session in which the SAS has not been initialized, or at least one in which your [DY]LD_LIBRARY_PATH is either empty or otherwise does not include the installed SAS directories.
    
    Similarly, after both SAS and HEASoft are installed, if they are initialized in the same session (terminal), C++-based tasks such as XSPEC may suffer runtime problems if the XMM-SAS library directories precede the one needed by XSPEC in [DY]LD_LIBRARY_PATH (as is the case if the SAS is initialized after HEASoft. As an example, if you compiled HEASoft on a Mac using the Homebrew compilers, XSPEC will need to have the Homebrew library path ahead of the SAS library directories in your DYLD_LIBRARY_PATH:

         For example:
    
         C-shell:
    
             setenv DYLD_LIBRARY_PATH "/usr/local/opt/gcc/lib/gcc/10:${DYLD_LIBRARY_PATH}
    
         Bourne shell:
    
             export DYLD_LIBRARY_PATH="/usr/local/opt/gcc/lib/gcc/10:${DYLD_LIBRARY_PATH}
      

    Additionally, when both the SAS & HEASoft are used in the same session and the SAS was initialized after HEASoft, the SAS setup changes the value of the environment variable PGPLOT_FONT with the result that plots in e.g. XSPEC may (or may not, depending on the software distributions in use) have no axis labels or values. Users can fix this by resetting PGPLOT_FONT to point to the HEASoft location:

         C-shell:
    
             setenv PGPLOT_FONT $HEADAS/lib/grfont.dat
    
         Bourne shell:
    
             export PGPLOT_FONT=$HEADAS/lib/grfont.dat
    
      

    or by simply re-initializing HEASoft:

         C-shell:
    
             source $HEADAS/headas-init.csh
    
         Bourne shell:
    
             . $HEADAS/headas-init.sh
      

    This may in turn have consequences for plotting in XMM-SAS, in which case users may need to return PGPLOT_FONT to the SAS setting when using it for data analysis.

Web page maintained by: Bryan K. Irby