starlink / ast Goto Github PK

View Code? Open in Web Editor NEW

12.0 12.0 12.0 21.45 MB

Starlink AST Library

License: GNU Lesser General Public License v3.0

C 91.43% Makefile 0.12% Perl 0.10% Fortran 4.54% Shell 0.09% M4 0.05% TeX 3.60% Python 0.07%

astronomy c wcs

ast's Introduction

This directory contains the following directories:

libraries
Starlink Fortran/C libraries

applications
Starlink Fortran/C applications

etc
Starlink initialisation scripts

buildsupport
Starlink support applications required to build configure-based
Starlink applications.

thirdparty
Third party applications and libraries required to build
Starlink classic applications

pubs
Starlink publications

docs
General documentation not associated with a particular application
or library.

Building the Starlink source set from scratch
---------------------------------------------

To build the COMPLETE set of Starlink classic applications the following steps
are required. If you wish to do more elaborate things, then you should refer
to Starlink document SSN/78, which also contains some FAQs. Details of this
document are at the end of this README.

This procedure will not build the Starlink _Java_ applications. They are
built separately, using the procedure described in Java README
(currently these are available from the git repository at
https://github.com/Starlink/starjava.git). You do not need to build any of
the Starlink classic applications to build the Java ones, unless you need to
rebuild the native parts of JNIAST, JNIHDS or SPLAT. To build the documents
for the Starjava applications FROG and SPLAT you will need the Starlink
applications star2html and the latex classes provided in latexsupport.

Preparation
-----------

- Ensure the required software development tools and headers are installed
on your system (see the "Prerequisites" section below)

- Specify where you want the installed files to end up (_PREFIX) and
where you want the build to find any previously installed Starlink
tree (_STARLINK). If there is no previously existing tree, then
set the two variables to the same value. Both variables default to
/star. You must have write access to the directory you name here.

Here and below we use /local-star as an example; in the examples
below substitute your own choice for this directory.

% setenv STARCONF_DEFAULT_STARLINK /local-star # csh
% setenv STARCONF_DEFAULT_PREFIX /local-star

% export STARCONF_DEFAULT_STARLINK=/local-star # sh
% export STARCONF_DEFAULT_PREFIX=/local-star

- Delete any previous Starlink environment variables.

% unsetenv INSTALL # csh
% unsetenv STARLINK

% unset INSTALL # sh
% unset STARLINK

and also make sure that an old-style Starlink system is not in your
PATH (since tools like messgen will get very confused).

You may also run into difficulties if you have previously sourced
the ${STARLINK}/etc/login and ${STARLINK}/etc/cshrc scripts that
existed from a previous classic mk-build Starlink install, as
even with $STARLINK removed from your PATH some applications may
still get confused at build time. If the login script in question
is a `new' one, from a previous autoconf install, you will
probably be fine (although you may need to remove installed
manifest files).

- Review any other environment variables that might affect the build.
For example, the variables F77, FC and CC will force the build
system to use the specified compilers. In particular, the default
IRAF installation sets the F77 variable to be a script which works
happily in most cases, but which will _not_ work with libtool, and
will cause the build to fail with opaque error messages about being
`unable to infer tagged configuration'. Unless you do wish to
force certain compilers to be used, it is probably better to unset
these variables before building the software. See './configure
--help' for a list of `some influential environment variables'.

This is good time to get the compilers that you're going to use
resolved, especially if you're not working on a GNU/Linux platform.
See the platform specific instructions later in this file.

At the time of writing (February 2009) it is known that the gfortran
compiler will work, but only from GCC4.3 onwards. If this is picked up by
default on your system you need to re-define FC and F77 to select another
compiler. For other versions of GCC4 you will need to use g95 (thanks to
Andy Vaught for his help with this), which is available from the g95 web
site: www.g95.org. For GCC3 based systems g77 should be used.

- Ensure that /tmp has sufficient free space and is writable.

- An example "sourceme" file for csh/tcsh is included in the repository.
You can customize it for your system and then use it to set up your
environment as described above.

The build sequence
------------------

To build the complete source distribution, you go through the steps:

% ./bootstrap
% make configure-deps
% ./configure -C
% make world

% cd thirdparty/perlsys/perlmods
% setenv STARLINK_DIR $STARCONF_DEFAULT_PREFIX # For csh-like shells.
% ./build-modules.sh

Each of these steps is described in detail below.

- First bootstrap the system.

This downloads third-party software, builds and installs the buildsupport
system (the tools in the buildsupport directory, plus third-party
applications autoconf, automake and libtool), and then goes on to generate
the configure scripts which will be used in the next step. The autoconf,
automake and libtool applications have been patched specifically for
building this tree so any versions shipped with the OS, or installed by
you, will _not_ work. These applications will be installed into
$STARCONF_DEFAULT_PREFIX/buildsupport, so you should add
$STARCONF_DEFAULT_PREFIX/buildsupport/bin to the front of your PATH
at this point, BEFORE you run the ./bootstrap script. In order for the
`make' below to work, you also need to add the default bin
directory to your PATH, so you should do that now.

# csh-like
% setenv PATH $STARCONF_DEFAULT_PREFIX/bin:$STARCONF_DEFAULT_PREFIX/buildsupport/bin:$PATH
% ./bootstrap

# sh-like
% PATH=$STARCONF_DEFAULT_PREFIX/bin:$STARCONF_DEFAULT_PREFIX/buildsupport/bin:$PATH
% ./bootstrap

This step takes a long while. Note that, although an important part of the
./bootstrap script is running autoreconf in the top-level directory,
you should not run autoreconf yourself in this directory.

- Build the configure dependencies.

There are a _few_ components which have to be built and installed
before the main tree is configured. You will have been advised of
this at the end of the bootstrap process above, but in case you
missed that, the command is

% make configure-deps

- Configure and build everything.

Now configure and build the system. The dependencies within the
Makefile ensure that everthing is built in the correct order.

% ./configure -C # -C means caching results
% make world

If you need to give ./configure some help to find include files and
libraries (for example, you are on a Mac and have installed Fink in
/sw or OpenDarwin in /opt/local, or are on a Sun and have extra
software in /opt), then do so by setting (for example)
CFLAGS=-I/opt/local/include and LDFLAGS=-L/opt/local/lib either in
the environment or, better, as arguments to the ./configure script.
Don't do this unless you discover you have to.

Each of these steps can also take some non-trivial time.

- Finally install the Perl modules.

The Perl modules can be installed using the build-modules.sh script
in the perlmods directory. This script requires that the environment
variable STARLINK_DIR be set to the Starlink installation into which
you would like to install the Perl modules, i.e. $STARCONF_DEFAULT_PREFIX.

% cd thirdparty/perlsys/perlmods
% ./build-modules.sh

This will install or update if needed the dependencies from CPAN and
then install all the modules present in the perlmods directory itself.

Additional hints
----------------

- Disabling shared libraries

If you wish to disable the building of shared libraries you should
use the --disable-shared configure option when you give the
./configure command above.

% ./configure -C --disable-shared

- Disabling the documentation

By default, the system will be configured so that all documentation
is built at the same time as the software. For this to work, you
must have LaTeX installed on your machine. Building the documentation
is rather slow, and you can speed up the build somewhat by omitting it.
You do that as follows:

% ./configure -C --without-stardocs

- Disabling build of VTK and associated software

By default VTK is built as a requirement of GAIA 3D and mesa is built
if OpenGL libraries are not present. These components may be omitted
using the following option:

% ./configure -C --without-vtk

- Building a single library or application

If you wish to build only as far as a given component, then specify
it by giving the name of the associated `manifest' file.

% make /local-star/manifests/ast

This will build, and install under STARCONF_DEFAULT_PREFIX, this
component and _everything it depends on to be built_.

Using the Newly-built System
----------------------------

To activate the Starlink system which you have just built, set the
STARLINK_DIR environment variable to the install location (as
chosen with STARCONF_DEFAULT_PREFIX) and source the cshrc and login
files (for csh/tcsh) or profile file (for bash).

% setenv STARLINK_DIR /local-star
% source ${STARLINK_DIR}/etc/cshrc
% source ${STARLINK_DIR}/etc/login

Developing individual components
--------------------------------

Note that this sequence of

./bootstrap; make configure-deps; ./configure -C; make world

is indeed a `make world' command -- it builds everything in the repository
that has been brought into the configure-based system, and will fail if some
components have not been checked out. If you wish to build or develop a
specific component, the instructions are slightly different.

- Specify the _PREFIX and _STARLINK variables as before, though this
time it might be appropriate to give them different values, if you
want to build against one installation tree (_STARLINK), but
install into another (_PREFIX). As above, unset the INSTALL and
STARLINK variables, and make sure there is no old-style Starlink
system in your PATH.

- If you have already built the buildsupport tools (autoconf,
automake, libtool and starconf), then make sure these are in your
PATH. If they are not built, or if you are not sure they are
up-to-date, you can build just these by going to the top-level of
your checkout and giving the command

% ./bootstrap --buildsupport

- Now you can go into a specific directory and build the library or
application as normal (a bootstrap is required in the directory if
you are building from a git checkout)

% ./bootstrap
% ./configure
% make
% make install

- After updating a component from the repository, it is possible that some
generated files will be out of date (if configure.ac or Makefile.am
had been updated). Any required updating is generally handled
automatically by makefile rules, but if you wish to guarantee that
everything is up to date, then you can give the command
`autoreconf'. This does no harm in any case, since it does nothing
if it is not required. As noted above, the exception to this is
that you should not run autoreconf in the top-level directory.

Updating the source set
-----------------------

The `make world' command will not _re_build the tree after you do an update
from the source repository, possibly unexpectedly. For a detailed explanation
of why this is so, see the `General FAQs' in SSN/78, described below.

You should also run the ./update-modules script after performing an update
of the source set from the main repository. This will make sure that any
thirdparty code is also updated.

Platform specific build notes
-----------------------------

- GNU/Linux

Currently (February 2009) the source set is known to build on many different
flavours of GNU/Linux and is actively developed using these. The only expected
issue is that of Fortran compiler support (C, C++ and Fortran compilers are
required to build the complete collection).

After the release of GCC 4 the Fortran compiler "g77" has been replaced with a
completely new "gfortran" (that now implements Fortran 90, 95 and some 2003
features), which has not been compatible with Starlink Fortran until the
release of version 4.3. Happily this turned out to be not a major problem
(thanks to Andy Vaught) as the other free Fortran compiler "g95", is
compatible. So to build the collection with a GCC 4+ compiler you'll either
need a copy of "g95" which is available from "www.g95.org", or more a very
recent version of gfortran (this can be checked by running gfortran -v).

To make sure you use the "g95" or "gfortran" compilers as required it is best
to define the environment variables "FC" and "F77":

% setenv FC g95 # csh
% setenv F77 g95
or
% export FC=g95 # sh
% export F77=g95

% setenv FC gfortran # csh
% setenv F77 gfortran
or
% export FC=gfortran # sh
% export F77=gfortran

before running "configure".

- Ubuntu (>= 11.04 "Natty Narwhal) / Debian

As of version 11.04 of Ubuntu the default handling of shared library
linking has changed. In the past indirect linking was enabled, such
that a program could link library "A", which in turn uses library
"B", and without explicitly linking the latter, routines from "B"
would be available (a situation that occurs in Starlink). Now that
this capability has been disabled, you will likely see strange
linker errors if you follow verbatim the build instructions as
described earlier in this document.

To remedy this situation you need to re-activate indirect linking
with LDFLAGS when configuring the build:

% ./configure -C LDFLAGS=-Wl,--no-as-needed

Ubuntu explain the issue here:

https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition

According to the following web page, this problem will also occur with
Debian (as of the Wheezy release), although it has not been tested:

http://wiki.debian.org/ToolChain/DSOLinking

Bootstrap in thirdparty/kitware/vtk may fail during bootstrap of cmake
if QT5 devel packges are installed on the local system. The answer
seems to be to remove such packages before building starlink,
reinstalling them again afterwards if necessary..

- macOS

The build situation under macOS follows much like that of GNU/Linux,
but you'll need to install your own Fortran compiler. In 10.3
the "g77" compiler from "Fink" or "MacPorts" has been used successfully,
in 10.4 you'll need a copy of "g95". For 10.5 or later you can use
g95, or gfortran. The latter is available from hpc.sourceforge.net
as well as MacPorts.

Note you'll also need to install X11 (see http://xquartz.macosforge.org),
and a functioning TeX and Ghostscript if you want to build the
documents. The build on macOS is not relocatable.

- Solaris

The collection is known to build under Solaris 8 (sparc) and 10 (intel),
using the SUN compilers (Workshop 6 and studio 11 respectively). To make
sure the correct compilers are picked up, you should define:

% setenv FC f77 # csh
% setenv F77 f77
% setenv CC cc
% setenv CXX CC
or
% export FC=f77 # sh
% export F77=f77
% export CC=cc
% export CXX=CC

Further information
-------------------

You should consult the project web pages at <http://www.starlink.ac.uk>,
<http://starlink.eao.hawaii.edu> and consider subscribing to the Starlink
development and user mailing lists: see
<http://www.jiscmail.ac.uk/archives/starlink.html> and
<http://www.jiscmail.ac.uk/archives/stardev.html>.

Starlink document SSN/78 gives much more detailed information on the
process of building Starlink classic applications, but this document
is primarily concerned with documenting the build system itself, and
describing how to add new components to the build-system repository.
The source for this document is in the repository at docs/ssn/078, and
a built version should be available on the Starlink web pages. A
version is also currently (May 2006) available at
<http://www.astro.gla.ac.uk/users/norman/star/ssn78/>.

This document contains some FAQs: a few of these will likely be of
interest to thise building the system from a checkout, though most
address quite specific details of how to configure software to work
within the Starlink source tree.

git repository
--------------

In February 2009 the Starlink source code was moved to a git repository
on github. This is described by a wiki at:

http://starlink.eao.hawaii.edu/

The build procedures described above are still correct, but much of the
associated documentation, SSN/78 etc. are becoming rapidly out-of-date.
Consult the wiki for download instructions and how to access things like
specific releases.

Prerequisites
-------------

This section lists some of the software development tools and headers
that are required to build Starlink. The list is not exhastive, but is
just a suggestion of some packages to check that may not not be provided
by default by your operating system. To build the documentation on any system
will require a reasonably complete up-to-date TeX install that includes the
TeX4HT system -- for example, a recent TeXLive installation which includes
a variety of standard packages.

Ubuntu:
git
build-essential (includes libc6-dev libc-dev gcc g++ make dpkg-dev)
gfortran (or g95)
libxext-dev
libxau-dev
libx11-dev
libxt-dev
xutils-dev
libncurses-dev
flex
bison
byacc
latex
texlive-latex-base
texlive-latex-extra
texlive-science
latex-color
pgf
tex4ht
texlive-fonts-extra
cm-super
texinfo
texi2html
libglu1-mesa-dev
freeglut3-dev
mesa-common-dev
zlib1g-dev
curl
libssl-dev
libexpat1-dev
libjpeg-turbo8-dev

Fedora:
Mainly as for Ubuntu, but note that package names are usually changed
from "libxyz-dev" to "libXyz-devel".

libXt-devel
ncurses-devel
makedepend

For the new documentation build, it may be necessary to install the
following (at least on Fedora 20 and 21):
texlive-latex
texlive-tex4ht.noarch
texlive-siunitx.noarch
texlive-titlesec.noarch
texlive-abstract.noarch
texlive-multirow.noarch
texlive-mdframed.noarch
texlive-titling.noarch
texlive-tocloft.noarch
texlive-eqparbox.noarch

Fedora 31:
flex
byacc
bison
libXt-devel
libXau-devel
libXext-devel
imake
libpng-devel
openssl-devel
expat-devel
texi2html
texinfo
texlive-scheme-full (a subset may be sufficient)

To build perl-JCMT-Tau package in perlmods, the following packages may
need to be added to the text file thirdparty/perlsys/perlmods/cpan_deps.

XML::Parser
SOAP::Lite

Debian 10:
This list (kindly provided by Paul Kerry), may not be complete and
some packages may be superfluous..

bison
byacc
ed
flex
g++
gcc
git
gfortran
libc6-dev
libcurl4-openssl-dev
libexpat1-dev
libxext-dev
libffi-dev
libfreetype6-dev
libgfortran5
libice-dev
libjpeg62-turbo-dev
libncurses-dev
libpng-dev
libsm-dev
libssl-dev
libx11-dev
libxau-dev
libxcb1-dev
libxdmcp-dev
libxt-dev
make
texinfo
texlive-full
uuid-dev
xutils-dev
zlib1g-dev

Arch Linux:
base-devel
ed
gcc-fortran
ghostscript
git
libx11
libxt
netpbm
tcsh
texlive-most

CentOS 7:
libXext-devel
libXau-devel
libX11-devel
libXt-devel
libxml2-devel
ncurses-devel
texlive-multirow

Rocky Linux 8:
Group: "Development Tools"
gfortran
libX11-devel
libXext-devel
libXt-devel
libxml2-devel
ncurses-devel
texinfo
libglvnd-opengl
mesa-libGLw
freeglut-devel
openssl-devel
expat-devel
libjpeg-turbo-devel

macOS:
gfortran
XCode
xcode commandline tools

ast's People

Contributors

Stargazers

Watchers

Forkers

lsst-dm markccchiang demitri othello1111 grahambell nirvananimbusa mfkiwl

ast's Issues

Create README for this repo.

I'd like to request a detailed README be written for this repo. This is a great project that should be documented and advertised as such, and GitHub READMEs have become the first port of call for these kinds of things. Suggestions for inclusion:

features and functionality of AST
some history showing how long it's been developed
projects/surveys that use AST
a note on the funding level compared to its impact
directions on installation, specific to the C version here
pointers to other versions
link to documentation
issues to be aware of for people who use the code (see #6)
pretty pictures

I'm a big fan of this library and would like to see its visibility increase. Thanks to all for the work on it!

PM_STACK_MAXSIZE gets exceeded easily in a multi-threaded environment

As part of "due diligence", evaluating Starlink AST to see if it can be adopted server-side by our FITSWEBQLSE, I've run into a problem when running a multi-threaded test program:

astBeginPM: Maximum stack size has been exceeded (internal AST programming error).

Using a small number of threads (i.e. 32) is fine

chris@capricorn:~/projects/FITSWEBQLSE/tests> ./test_starlink 10 32
Testing Starlink AST for 10 seconds using 32 threads.
All Starlink AST threads terminated
astFlushMemory: All AST memory blocks were released correctly.

Increasing the number of threads to, say, 64 or 128 often (not always but in most cases) results in memory errors. The PM_STACK_MAXSIZE of 20 seems to be getting exceeded rather too easily, despite there being only a one level of depth in perfectly matching astBegin and astEnd calls:

chris@capricorn:~/projects/FITSWEBQLSE/tests> ./test_starlink 10 64
Testing Starlink AST for 10 seconds using 64 threads.
!! AST: Error in routine test_fk4 at line 23 in file test_starlink.c.
!  astBeginPM: Maximum stack size has been exceeded (internal AST programming error).
!! astBeginPM: Maximum stack size has been exceeded (internal AST programming error).
!! AST: Error in routine test_fk4 at line 23 in file test_starlink.c.
!  astBeginPM: Maximum stack size has been exceeded (internal AST programming error).
!! AST: Error in routine test_fk4 at line 23 in file test_starlink.c.
!  astBeginPM: Maximum stack size has been exceeded (internal AST programming error).
!  astTimeFrame: Inappropriate units (d) specified for a (null) axis.
!! AST: Error in routine test_fk4 at line 23 in file test_starlink.c.
!  astBeginPM: Maximum stack size has been exceeded (internal AST programming error).
!! AST: Error in routine test_fk4 at line 22 in file test_starlink.c.
!  astBeginPM: Maximum stack size has been exceeded (internal AST programming error).
!! AST: Error in routine test_fk4 at line 23 in file test_starlink.c.
!  astBeginPM: Maximum stack size has been exceeded (internal AST programming error).
!! AST: Error in routine test_fk4 at line 23 in file test_starlink.c.
!  astBeginPM: Maximum stack size has been exceeded (internal AST programming error).
!! AST: Error in routine test_fk4 at line 23 in file test_starlink.c.
!  astEndPM: astEndPM called without matching astBeginPM (internal AST programming error).
!! AST: Error in routine test_fk4 at line 23 in file test_starlink.c.
!  astEndPM: astEndPM called without matching astBeginPM (internal AST programming error).
!! AST: Error in routine test_fk4 at line 23 in file test_starlink.c.
!  astEndPM: astEndPM called without matching astBeginPM (internal AST programming error).
!! AST: Error in routine test_fk4 at line 23 in file test_starlink.c.
!  astEndPM: astEndPM called without matching astBeginPM (internal AST programming error).
!! AST: Error in routine test_fk4 at line 23 in file test_starlink.c.
!  astEndPM: astEndPM called without matching astBeginPM (internal AST programming error).
!! AST: Error in routine test_fk4 at line 22 in file test_starlink.c.
!  astEndPM: astEndPM called without matching astBeginPM (internal AST programming error).
!! AST: Error in routine test_fk4 at line 39 in file test_starlink.c.
!  astEnd: Invalid use of astEnd without a matching astBegin.
!! AST: Error in routine test_fk4 at line 23 in file test_starlink.c.
!  astEndPM: astEndPM called without matching astBeginPM (internal AST programming error).
All Starlink AST threads terminated
!! AST: Error in routine main at line 134 in file test_starlink.c.
!  astFlushMemory: 1 AST memory blocks have not been released (programming error).

The AST documentation (inside memory.c) states

Matching pairs of astBeginPM/astEndPM calls can be nested up to a

```
maximum depth of 20.
```

yet my test code definitely does not use any nesting (the level is 1).

The existence of hard limits such as PM_STACK_MAXSIZE makes me somewhat wary of using AST in a 24-hour multi-threaded server environment as it is difficult to anticipate in advance if / when any internal hard-coded AST limits might get exceeded. There might be other similar hard limits that Starlink AST end-users might not be aware of ... Do you think this is something that the AST project might improve in the near future?

Compile command: cc pkg-config --cflags cfitsio-o test_starlink test_starlink.c -L/usr/local/libast_link -pthread
AST has been configured / compiled with ./configure --prefix=/usr/local --with-memdebug
Test source code: test_starlink.c
test_starlink.c.txt

AST compile issues on Windows and non-gcc compilers

I'm trying to put together a build script for AST for vcpkg, which will make building and distributing AST-based software on Windows platforms far simpler. I've run into a few gcc-specific functions in the code, and I've attached a patch to fix these. The other build issue is that the Makefile.in file is missing a few $(EXEEXT) values.

The specific issues are:

incrementing a void* pointer is only allowed in GCC (See https://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c)
An explicit cast to void, rather than to void* when using astSetSourceVel

@dsberry please see attached zip for patches to fix these issues. I'm not sure if this is the correct solution though. Should Makefile.in or Makefile.am be changed?

patches_ast.zip

Write CDi_j even when zero

Our users have requested that CDi_j be written even if they're zero. The FITS WCS standard says that these keywords are interpreted as zero if missing, but makes no statement about whether they should be present or not if zero.

Can we add an attribute controlling whether CDi_j will be written if they're zero? I'm happy to do the work if this is approved.

ast fails to build in macOS-11 MacPorts environment

Although I can successfully build ast-9.2.4 with a simple:

curl -O https://github.com/Starlink/ast/releases/download/v9.2.4/ast-9.2.4.tar.gz
tar -zxf ast-9.2.4.tar.gz
cd ast-9.2.4
./confiure
make

It fails to build in a MacPorts build environment in a macOS-11.4 + Xcode-12.5 environment. (In general, the "MacPorts build environment" is stricter than a "normal" one, and thus catches coding errors that otherwise are perhaps only warnings in a "normal" environment.)

The currently supported ast version in the official MacPorts repository is 9.0.1, but even if I update the Portfile to use 9.2.4, I get the same set of errors, which is:

libtool: link: /usr/bin/clang -dynamiclib -o .libs/libast.9.dylib src/.libs/libast_la-yamlchan.o src/.libs/libast_la-axis.o src/.libs/libast_la-box.o src/.libs/libast_la-channel.o src/.libs/libast_la-chebymap.o src/.libs/libast_la-circle.o src/.libs/libast_la-cmpframe.o src/.libs/libast_la-cmpmap.o src/.libs/libast_la-cmpregion.o src/.libs/libast_la-dsbspecframe.o src/.libs/libast_la-dssmap.o src/.libs/libast_la-ellipse.o src/.libs/libast_la-error.o src/.libs/libast_la-fitschan.o src/.libs/libast_la-fitstable.o src/.libs/libast_la-fluxframe.o src/.libs/libast_la-frame.o src/.libs/libast_la-frameset.o src/.libs/libast_la-globals.o src/.libs/libast_la-grismmap.o src/.libs/libast_la-interval.o src/.libs/libast_la-intramap.o src/.libs/libast_la-keymap.o src/.libs/libast_la-loader.o src/.libs/libast_la-lutmap.o src/.libs/libast_la-mapping.o src/.libs/libast_la-mathmap.o src/.libs/libast_la-matrixmap.o src/.libs/libast_la-memory.o src/.libs/libast_la-moc.o src/.libs/libast_la-mocchan.o src/.libs/libast_la-normmap.o src/.libs/libast_la-nullregion.o src/.libs/libast_la-object.o src/.libs/libast_la-pcdmap.o src/.libs/libast_la-permmap.o src/.libs/libast_la-plot.o src/.libs/libast_la-plot3d.o src/.libs/libast_la-pointlist.o src/.libs/libast_la-pointset.o src/.libs/libast_la-polygon.o src/.libs/libast_la-polymap.o src/.libs/libast_la-prism.o src/.libs/libast_la-ratemap.o src/.libs/libast_la-region.o src/.libs/libast_la-selectormap.o src/.libs/libast_la-shiftmap.o src/.libs/libast_la-skyaxis.o src/.libs/libast_la-skyframe.o src/.libs/libast_la-slamap.o src/.libs/libast_la-specfluxframe.o src/.libs/libast_la-specframe.o src/.libs/libast_la-specmap.o src/.libs/libast_la-sphmap.o src/.libs/libast_la-stc.o src/.libs/libast_la-stccatalogentrylocation.o src/.libs/libast_la-stcobsdatalocation.o src/.libs/libast_la-stcresourceprofile.o src/.libs/libast_la-stcschan.o src/.libs/libast_la-stcsearchlocation.o src/.libs/libast_la-switchmap.o src/.libs/libast_la-table.o src/.libs/libast_la-timeframe.o src/.libs/libast_la-timemap.o src/.libs/libast_la-tranmap.o src/.libs/libast_la-unit.o src/.libs/libast_la-unitmap.o src/.libs/libast_la-unitnormmap.o src/.libs/libast_la-wcsmap.o src/.libs/libast_la-winmap.o src/.libs/libast_la-xml.o src/.libs/libast_la-xmlchan.o src/.libs/libast_la-xphmap.o src/.libs/libast_la-zoommap.o src/.libs/libast_la-fyamlchan.o src/.libs/libast_la-c2f77.o src/.libs/libast_la-fbox.o src/.libs/libast_la-fchannel.o src/.libs/libast_la-fchebymap.o src/.libs/libast_la-fcircle.o src/.libs/libast_la-fcmpframe.o src/.libs/libast_la-fcmpmap.o src/.libs/libast_la-fcmpregion.o src/.libs/libast_la-fdsbspecframe.o src/.libs/libast_la-fdssmap.o src/.libs/libast_la-fellipse.o src/.libs/libast_la-ferror.o src/.libs/libast_la-ffitschan.o src/.libs/libast_la-ffitstable.o src/.libs/libast_la-ffluxframe.o src/.libs/libast_la-fframe.o src/.libs/libast_la-fframeset.o src/.libs/libast_la-fgrismmap.o src/.libs/libast_la-finterval.o src/.libs/libast_la-fintramap.o src/.libs/libast_la-fkeymap.o src/.libs/libast_la-flutmap.o src/.libs/libast_la-fmapping.o src/.libs/libast_la-fmathmap.o src/.libs/libast_la-fmatrixmap.o src/.libs/libast_la-fmoc.o src/.libs/libast_la-fmocchan.o src/.libs/libast_la-fnormmap.o src/.libs/libast_la-fnullregion.o src/.libs/libast_la-fobject.o src/.libs/libast_la-fpcdmap.o src/.libs/libast_la-fpermmap.o src/.libs/libast_la-fplot.o src/.libs/libast_la-fplot3d.o src/.libs/libast_la-fpointlist.o src/.libs/libast_la-fpolygon.o src/.libs/libast_la-fpolymap.o src/.libs/libast_la-fprism.o src/.libs/libast_la-fratemap.o src/.libs/libast_la-fregion.o src/.libs/libast_la-fselectormap.o src/.libs/libast_la-fshiftmap.o src/.libs/libast_la-fskyframe.o src/.libs/libast_la-fslamap.o src/.libs/libast_la-fspecfluxframe.o src/.libs/libast_la-fspecframe.o src/.libs/libast_la-fspecmap.o src/.libs/libast_la-fsphmap.o src/.libs/libast_la-fstc.o src/.libs/libast_la-fstccatalogentrylocation.o src/.libs/libast_la-fstcobsdatalocation.o src/.libs/libast_la-fstcresourceprofile.o src/.libs/libast_la-fstcschan.o src/.libs/libast_la-fstcsearchlocation.o src/.libs/libast_la-fswitchmap.o src/.libs/libast_la-ftable.o src/.libs/libast_la-ftimeframe.o src/.libs/libast_la-ftimemap.o src/.libs/libast_la-ftranmap.o src/.libs/libast_la-funitmap.o src/.libs/libast_la-funitnormmap.o src/.libs/libast_la-fwcsmap.o src/.libs/libast_la-fwinmap.o src/.libs/libast_la-fxmlchan.o src/.libs/libast_la-fzoommap.o cminpack/.libs/libast_la-lmder1.o cminpack/.libs/libast_la-lmder.o cminpack/.libs/libast_la-dpmpar.o cminpack/.libs/libast_la-enorm.o cminpack/.libs/libast_la-qrfac.o cminpack/.libs/libast_la-lmpar.o cminpack/.libs/libast_la-qrsolv.o wcslib/.libs/libast_la-proj.o wcslib/.libs/libast_la-tpn.o wcslib/.libs/libast_la-wcstrig.o -L/stardev/git/starlink/star/lib -L/opt/local/lib ./.libs/libast_pal.dylib -lyaml -lpthread -Os -arch x86_64 -Wl,-headerpad_max_install_names -Wl,-syslibroot -Wl,/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64 -install_name /opt/local/lib/libast.9.dylib -compatibility_version 12 -current_version 12.4 -Wl,-single_module
Undefined symbols for architecture x86_64:
"_astG3DAttr", referenced from:
_Attr3D in libast_la-plot3d.o
_Plot3DAttr in libast_la-plot3d.o
"_astG3DCap", referenced from:
_Plot3DCap in libast_la-plot3d.o
"_astG3DFlush", referenced from:
_Plot3DFlush in libast_la-plot3d.o
"_astG3DLine", referenced from:
_Border in libast_la-plot3d.o
_Plot3DLine in libast_la-plot3d.o
"_astG3DMark", referenced from:
_Mark in libast_la-plot3d.o
_Plot3DMark in libast_la-plot3d.o
"_astG3DQch", referenced from:
_Plot3DQch in libast_la-plot3d.o
"_astG3DText", referenced from:
_Text in libast_la-plot3d.o
_Plot3DText in libast_la-plot3d.o
"_astG3DTxExt", referenced from:
_Plot3DTxExt in libast_la-plot3d.o
"_astGAttr", referenced from:
_GAttr in libast_la-plot.o
"_astGBBuf", referenced from:
_BBuf in libast_la-plot.o
"_astGCap", referenced from:
_GCap in libast_la-plot.o
"_astGEBuf", referenced from:
_EBuf in libast_la-plot.o
"_astGLine", referenced from:
_GLine in libast_la-plot.o
"_astGMark", referenced from:
_Mark in libast_la-plot.o
"_astGQch", referenced from:
_DrawText in libast_la-plot.o
"_astGScales", referenced from:
_GScales in libast_la-plot.o
"_astGText", referenced from:
_GText in libast_la-plot.o
"_astGTxExt", referenced from:
_GTxExt in libast_la-plot.o
"astPutErr", referenced from:
_PutErr in libast_la-error.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libast.la] Error 1
make[1]: Leaving directory `/opt/local/var/macports/build/_private_tmp_vjpd-ast/ast/work/ast-9.2.4'
make: *** [all] Error 2

I can make MOST of these missing symbols go away by adding the following objects to the list to be included in the library:

   src/.libs/libast_drama_la-err_drama.o
   src/.libs/libast_grf3d_la-grf3d.o
   src/.libs/libast_grf_2_0_la-grf_2.0.o
   src/.libs/libast_grf_5_6_la-grf_5.6.o
   src/.libs/libast_grf_3_2_la-grf_3.2.o

However these objects only exist if make is invoked with (8) parallel jobs. If I invoke with no make parallelisation then these objects do not exist at the time the above library is being made.

But even when they do exist and are all added to the above compile command, I then still get the following error:

Undefined symbols for architecture x86_64:
"_ErsRep", referenced from:
astPutErr in libast_drama_la-err_drama.o
ld: symbol(s) not found for architecture x86_64

I can't find an object with a _ErsRep definition. Maybe it's a question of ordering and dependency...

So I think there are some missing dependency definitions that mean all the required objects are not built nor included at the moment that they are required for building the library(ies).

Any chance this can be fixed?

building in separate directory

Running configure from a separate folder (and using --disable-fortran, although this might occur even with fortran) causes an error, because makeh and ast_par.source are not in the build directory, but rather in the source directory.

I solved this issue manually by copying makeh and ast_par.source to the build directory, but this should probably be fixed in the build configuration.

Related: should ast_par.source be required at all if running with --disable-fortran?

calling AST from Fortran 90

It seems the Fortran bindings in AST are terribly, terribly outdated and cannot be used together with, for example, Fortran 90 or newer.

The 'AST_PAR' file uses old fixed-form FORTRAN 77. Even after converting it to newer free-form Fortran 90 and including it in a new Modern Fortran 2018 project, the AST functions cannot be called from within Fortran.

Frankly, the entire Fortran interface to AST needs a complete overhaul to make use of modern C <--> Fortran 2018 interoperability, each AST function should have a proper interface to C with all the function arguments listed explicitly etc., instead of being plain INTEGER types, and the Fortran interface file should be made a Fortran module.

It is a lot of work for the AST team but, as things stand at the moment, it is impossible to use Starlink AST in Fortran right now. I've been trying to switch from WCSLIB to AST in my Fortran 2018 code but had to give up.

Is Fortran not loved anymore? Surely this is not the case.

compiling with an external copy of cminpack

Is it possible to compile AST with an external copy of cminpack, rather than using the supplied copy? I'm trying to update the vcpkg port (see PR microsoft/vcpkg#20559 for details), but am getting pushback from their maintainers due to the use of cminpack, rather than relying on a separate shared DLL for it.

Trouble building with external pal

I'm working on changing the Fedora ast package to build with an external pal lib. However, I'm running into a couple issues:

Fedora does not ship .la files, but ast is trying to link to $(libdir)/libpal.la. I've changed this to -lpal.
ast_test does not appear to consider the conditional and still references @LIBPAL@, @LIBCMINPACK@, libast_pal.la and libast_cminpack.la in LDADD and DEPENDENCIES

ast.h subject to collision with python's ast.h in some build processes

When compiling ast, by not placing the headers under a starlink directory, you are subject to collisions with python's ast.h.

For example, the following would fail because it will pick up python's ast.h first:

g++ -o src/MapSplit.os -c -std=c++14 -g -O3 -Wall -Wno-unused-function -fPIC \
  -Iinclude \
  -isystem /opt/conda/envs/default/include/python3.7m \
  -isystem /slac/opt/conda/envs/default/include \
   src/MapSplit.cc

While changing the order will succeed:

g++ -o src/MapSplit.os -c -std=c++14 -g -O3 -Wall -Wno-unused-function -fPIC \
  -Iinclude \
  -isystem /slac/opt/conda/envs/default/include \
  -isystem /opt/conda/envs/default/include/python3.7m \
   src/MapSplit.cc

Supporting ast in conda-forge

Hi,

I've started adding a conda-forge recipe for ast (under the name starlink-ast) for the support of LSST code:

conda-forge/staged-recipes#8828

I'd be interested if you'd like me to list anyone as additional maintainers of that recipe, or if you have any desires as to how the build script and testing may be ideally performed.

Thanks

Compiler warnings with clang on macOS

Some minor compiler warnings with 9.2.5:

/bin/sh ./libtool  --tag=CC   --mode=compile clang -DHAVE_CONFIG_H -I.  -I/stardev/git/starlink/star/include    -prefer-pic  -DYAML -g -O2 -MT src/libast_la-moc.lo -MD -MP -MF src/.deps/libast_la-moc.Tpo -c -o src/libast_la-moc.lo `test -f 'src/moc.c' || echo './'`src/moc.c
libtool: compile:  clang -DHAVE_CONFIG_H -I. -I/stardev/git/starlink/star/include -DYAML -g -O2 -MT src/libast_la-moc.lo -MD -MP -MF src/.deps/libast_la-moc.Tpo -c src/moc.c  -fno-common -DPIC -o src/.libs/libast_la-moc.o
src/moc.c:618:17: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                npix, MaxNpix( order ) + 1 );
                ^~~~
src/moc.c:1435:57: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                                  "end (%zu).", status, npix0, npix );
                                                        ^~~~~
src/moc.c:1435:64: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                                  "end (%zu).", status, npix0, npix );
                                        ~~~                    ^~~~
                                        %lld
src/moc.c:3056:32: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                               plist->value );
                               ^~~~~~~~~~~~
src/moc.c:3088:67: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                            "error).", status, astGetClass(this), plist->value );
                                                                  ^~~~~~~~~~~~
src/moc.c:3111:48: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                            astGetClass(this), plist->value );
                                               ^~~~~~~~~~~~
src/moc.c:3145:67: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                            "error).", status, astGetClass(this), plist->value );
                                                                  ^~~~~~~~~~~~
src/moc.c:3171:48: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                            astGetClass(this), plist->value );
                                               ^~~~~~~~~~~~
src/moc.c:3212:23: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                      pcur[ 0 ], pcur[ 1 ] );
                      ^~~~~~~~~
src/moc.c:3212:34: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                      pcur[ 0 ], pcur[ 1 ] );
                                 ^~~~~~~~~
src/moc.c:3220:37: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                            irange, pnew[ 0 ], pnew[ 1 ] );
                                    ^~~~~~~~~
src/moc.c:3220:48: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                            irange, pnew[ 0 ], pnew[ 1 ] );
                                               ^~~~~~~~~
src/moc.c:3227:29: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                            pcur[ 0 ], pcur[ 1 ], irange, pnew[ 0 ], pnew[ 1 ] );
                            ^~~~~~~~~
src/moc.c:3227:40: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                            pcur[ 0 ], pcur[ 1 ], irange, pnew[ 0 ], pnew[ 1 ] );
                                       ^~~~~~~~~
src/moc.c:3227:59: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                            pcur[ 0 ], pcur[ 1 ], irange, pnew[ 0 ], pnew[ 1 ] );
                                                          ^~~~~~~~~
src/moc.c:3227:70: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                            pcur[ 0 ], pcur[ 1 ], irange, pnew[ 0 ], pnew[ 1 ] );
                                                                     ^~~~~~~~~
src/moc.c:4902:34: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                          order, npix );
                                 ^~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
  __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
                                                       ^~~~~~~~~~~
src/moc.c:4902:34: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                          order, npix );
                                 ^~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
  __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
                                                       ^~~~~~~~~~~
src/moc.c:4909:42: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
            nc = sprintf( token, ",%zu", npix );
                                   ~~~   ^~~~
                                   %lld
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
  __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
                                                       ^~~~~~~~~~~
src/moc.c:4920:45: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
               nc = sprintf( token, "-%zu", npix_prev );
                                      ~~~   ^~~~~~~~~
                                      %lld
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
  __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
                                                       ^~~~~~~~~~~
src/moc.c:4925:67: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
            nc = sprintf( token, first?"%d/%zu":" %d/%zu", order, npix );
                                           ~~~                    ^~~~
                                           %lld
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
  __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
                                                       ^~~~~~~~~~~
src/moc.c:4925:67: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
            nc = sprintf( token, first?"%d/%zu":" %d/%zu", order, npix );
                                                     ~~~          ^~~~
                                                     %lld
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
  __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
                                                       ^~~~~~~~~~~
src/moc.c:4933:45: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
               nc = sprintf( token, "-%zu", npix_prev );
                                      ~~~   ^~~~~~~~~
                                      %lld
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
  __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
                                                       ^~~~~~~~~~~
src/moc.c:4938:42: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
            nc = sprintf( token, ",%zu", npix );
                                   ~~~   ^~~~
                                   %lld
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
  __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
                                                       ^~~~~~~~~~~
src/moc.c:4952:39: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
         nc = sprintf( token, "-%zu", npix );
                                ~~~   ^~~~
                                %lld
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/secure/_stdio.h:47:56: note: expanded from macro 'sprintf'
  __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
                                                       ^~~~~~~~~~~
src/moc.c:8967:17: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                npix, MaxNpix( order ) + 1 );
                ^~~~
src/moc.c:10555:47: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                         "order %d.", status, pr[ 1 ], new->maxorder );
                                              ^~~~~~~
src/moc.c:10562:50: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                         "bound (%zu).", status, pr[ 1 ], pr[ 0 ] );
                                                 ^~~~~~~
src/moc.c:10562:59: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                         "bound (%zu).", status, pr[ 1 ], pr[ 0 ] );
                                 ~~~                      ^~~~~~~
                                 %lld
src/moc.c:10569:48: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                         "[%zu:%zu].", status, pr[ 0 ], pr[ 1 ], llast,
                                               ^~~~~~~
src/moc.c:10569:57: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                         "[%zu:%zu].", status, pr[ 0 ], pr[ 1 ], llast,
                                                        ^~~~~~~
src/moc.c:10569:66: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                         "[%zu:%zu].", status, pr[ 0 ], pr[ 1 ], llast,
                           ~~~                                   ^~~~~
                           %lld
src/moc.c:10570:26: warning: format specifies type 'size_t' (aka 'unsigned long') but the argument has type 'int64_t' (aka 'long long') [-Wformat]
                         ulast );
                         ^~~~~
33 warnings generated.

and

/bin/sh ./libtool  --tag=CC   --mode=compile clang -DHAVE_CONFIG_H -I.  -I/stardev/git/starlink/star/include    -prefer-pic  -DYAML -g -O2 -MT src/libast_la-yamlchan.lo -MD -MP -MF src/.deps/libast_la-yamlchan.Tpo -c -o src/libast_la-yamlchan.lo `test -f 'src/yamlchan.c' || echo './'`src/yamlchan.c
libtool: compile:  clang -DHAVE_CONFIG_H -I. -I/stardev/git/starlink/star/include -DYAML -g -O2 -MT src/libast_la-yamlchan.lo -MD -MP -MF src/.deps/libast_la-yamlchan.Tpo -c src/yamlchan.c  -fno-common -DPIC -o src/.libs/libast_la-yamlchan.o
src/yamlchan.c:5344:16: warning: expression result unused; should this cast be to 'void'? [-Wunused-value]
               (void *) astAnnul( new );
               ^     ~
src/yamlchan.c:5359:13: warning: expression result unused; should this cast be to 'void'? [-Wunused-value]
            (void *) astAnnul( *newmap );
            ^     ~
2 warnings generated.

and

/bin/sh ./libtool  --tag=CC   --mode=compile clang -DHAVE_CONFIG_H -I.  -I/stardev/git/starlink/star/include    -prefer-pic  -DYAML -g -O2 -MT src/libast_la-specframe.lo -MD -MP -MF src/.deps/libast_la-specframe.Tpo -c -o src/libast_la-specframe.lo `test -f 'src/specframe.c' || echo './'`src/specframe.c
libtool: compile:  clang -DHAVE_CONFIG_H -I. -I/stardev/git/starlink/star/include -DYAML -g -O2 -MT src/libast_la-specframe.lo -MD -MP -MF src/.deps/libast_la-specframe.Tpo -c src/specframe.c  -fno-common -DPIC -o src/.libs/libast_la-specframe.o
src/specframe.c:6129:14: warning: expression result unused; should this cast be to 'void'? [-Wunused-value]
             NULL),AST__BADSOR))
             ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.0.0/include/stddef.h:89:17: note: expanded from macro 'NULL'
#  define NULL ((void*)0)
                ^
src/specframe.c:6138:18: warning: expression result unused; should this cast be to 'void'? [-Wunused-value]
                 NULL), value:( astError( AST__ATTIN, "%s(%s): Bad value (%d) "
                 ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.0.0/include/stddef.h:89:17: note: expanded from macro 'NULL'
#  define NULL ((void*)0)
                ^
src/specframe.c:6196:70: warning: expression result unused; should this cast be to 'void'? [-Wunused-value]
                                         AST__VREL, status ) ),NULL):NULL),AST__BADSYSTEM))
                                                                     ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.0.0/include/stddef.h:89:17: note: expanded from macro 'NULL'
#  define NULL ((void*)0)
                ^
src/specframe.c:6207:80: warning: expression result unused; should this cast be to 'void'? [-Wunused-value]
                                                        value, status )),NULL):NULL),
                                                                               ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.0.0/include/stddef.h:89:17: note: expanded from macro 'NULL'
#  define NULL ((void*)0)
                ^
4 warnings generated.

tick artifact when using very large line width

hi:
currently we are using AST for rendering coordinate systems, really a great library, thanks for your effort! However we met a problem which is the tick artifact when using very large line width. I wonder why is there a strange triangle after the rectangular tick? Hope there could be a fix for this, thanks again!

Incorrect transform from FITS with N image axes and N+1 World axes

Hi @dsberry & co.,

Our pipeline at Gemini is writing out a WCS for long-slit spectra that has axes for wavelength, RA & Dec -- ie. one more axis than the 2D image array. Obviously both RA & Dec may vary along the slit (or not), depending on its position angle, so we have both CD2_2 & CD3_2 terms (in addition to CD1_1 for wavelength). When trying to display such an image with DS9 v8.0.1 or later (which was refactored to use AST), @chris-simpson and I have discovered that (in addition to a problem in DS9 itself) AST seems to implement the transforms described by the FITS header incorrectly, such that the 3rd World axis gets assigned a constant* value.

Here is a simplified example that illustrates the same behaviour using 1 pixel axis mapping to 2 World axes, rather than 2 to 3:

#include "fitsio.h"
#include "ast.h"

int main (int argc, char *argv[]) {

  fitsfile *fptr;
  AstFitsChan *fitschan;
  AstFrameSet *wcsinfo;
  char *header, *ctype="LINEAR";
  int n, nkeys, wcsaxes, crpix1, status=0;
  long naxes[1]={10};
  double crval1, crval2, cd1_1, cd2_1, pix[1], ipix[1], world[2]={};

  fits_create_file(&fptr, "!tmpast.fits", &status);

  fits_create_img(fptr, 16, 1, naxes, &status);

  wcsaxes = 2;
  crpix1 = 1;
  crval1 = 1.0;
  crval2 = 1.0;
  cd1_1 = 1.0;
  cd2_1 = 1.0;

  fits_update_key(fptr, TINT, "WCSAXES", &wcsaxes, NULL, &status);
  fits_update_key(fptr, TINT, "CRPIX1", &crpix1, NULL, &status);
  fits_update_key(fptr, TSTRING, "CTYPE1", ctype, NULL, &status);
  fits_update_key(fptr, TSTRING, "CTYPE2", ctype, NULL, &status);
  fits_update_key(fptr, TDOUBLE, "CRVAL1", &crval1, NULL, &status);
  fits_update_key(fptr, TDOUBLE, "CRVAL2", &crval2, NULL, &status);
  fits_update_key(fptr, TDOUBLE, "CD1_1", &cd1_1, NULL, &status);
  fits_update_key(fptr, TDOUBLE, "CD2_1", &cd2_1, NULL, &status);

  fits_hdr2str(fptr, 0, NULL, 0, &header, &nkeys, &status);

  fits_close_file(fptr, &status);

  astBegin;

  fitschan = astFitsChan( NULL, NULL, "" );
  astPutCards(fitschan, header);
  free(header);
  wcsinfo = astRead(fitschan);

  astShow(wcsinfo);
  printf("\n");

  for(n=1; n < 4; n++) {

    pix[0] = (double) n;

    /* Fwd: */
    astTranN(wcsinfo, 1, 1, 1, pix, 1, 2, 1, world);

    /* Inv: */
    astTranN(wcsinfo, 1, 2, 1, world, 0, 1, 1, ipix);

    printf("Pix %.3f -> World (%.3f, %.3f) -> pix %.3f\n",
           pix[0], world[0], world[1], ipix[0]);
    printf("       - should be (%.3f, %.3f)\n\n",
        (pix[0]-crpix1)*cd1_1 + crval1, (pix[0]-crpix1)*cd2_1 + crval2);

  }

  astEnd;

}

The output is as follows:

 Begin FrameSet 	# Set of inter-related coordinate systems
#   Title = "2-d coordinate system" 	# Title of coordinate system
#   Naxes = 2 	# Number of coordinate axes
#   Domain = "LINEAR-LINEAR" 	# Coordinate system domain
#   Lbl1 = "LINEAR" 	# Label for axis 1
#   Lbl2 = "LINEAR" 	# Label for axis 2
 IsA Frame 	# Coordinate system description
    Nframe = 2 	# Number of Frames in FrameSet
    Base = 1 	# Index of base Frame
    Currnt = 2 	# Index of current Frame
    Lnk2 = 1 	# Node 2 is derived from node 1
    Frm1 = 	# Frame number 1
       Begin Frame 	# Coordinate system description
          Title = "Pixel Coordinates" 	# Title of coordinate system
          Naxes = 1 	# Number of coordinate axes
          Domain = "GRID" 	# Coordinate system domain
#         Lbl1 = "Pixel axis 1" 	# Label for axis 1
          Ax1 = 	# Axis number 1
             Begin Axis 	# Coordinate axis
                Label = "Pixel axis 1" 	# Axis Label
             End Axis
       End Frame
    Frm2 = 	# Frame number 2
       Begin Frame 	# Coordinate system description
          Ident = " " 	# Permanent Object identification string
       IsA Object 	# AST Object
#         Title = "2-d coordinate system" 	# Title of coordinate system
          Naxes = 2 	# Number of coordinate axes
          Domain = "LINEAR-LINEAR" 	# Coordinate system domain
#         Lbl1 = "LINEAR" 	# Label for axis 1
#         Lbl2 = "LINEAR" 	# Label for axis 2
          Ax1 = 	# Axis number 1
             Begin Axis 	# Coordinate axis
                Label = "LINEAR" 	# Axis Label
                Symbol = "LINEAR" 	# Axis symbol
             End Axis
          Ax2 = 	# Axis number 2
             Begin Axis 	# Coordinate axis
                Label = "LINEAR" 	# Axis Label
                Symbol = "LINEAR" 	# Axis symbol
             End Axis
       End Frame
    Map2 = 	# Mapping between nodes 1 and 2
       Begin CmpMap 	# Compound Mapping
          Nin = 1 	# Number of input coordinates
          Nout = 2 	# Number of output coordinates
       IsA Mapping 	# Mapping between coordinate systems
          MapA = 	# First component Mapping
             Begin PermMap 	# Coordinate permutation
                Nin = 1 	# Number of input coordinates
                Nout = 2 	# Number of output coordinates
             IsA Mapping 	# Mapping between coordinate systems
                Out1 = 1 	# Output coordinate 1 = input coordinate 1
                Out2 = -1 	# Output coordinate 2 = constant no. 1
                In1 = 1 	# Input coordinate 1 = output coordinate 1
                Nconst = 1 	# Number of constants
                Con1 = 1 	# Constant number 1
             End PermMap
          MapB = 	# Second component Mapping
             Begin WinMap 	# Map one window on to another
                Nin = 2 	# Number of input coordinates
                IsSimp = 1 	# Mapping has been simplified
             IsA Mapping 	# Mapping between coordinate systems
                Sft2 = 1 	# Shift for axis 2
             End WinMap
       End CmpMap
 End FrameSet

Pix 1.000 -> World (1.000, 2.000) -> pix 1.000
       - should be (1.000, 1.000)

Pix 2.000 -> World (2.000, 2.000) -> pix 2.000
       - should be (2.000, 2.000)

Pix 3.000 -> World (3.000, 2.000) -> pix 3.000
       - should be (3.000, 3.000)

It appears that the PermMap is assigning Out2 to a constant rather than input coordinate 1 for some reason, though I'm not very familiar with all the AST structures, which seem quite complicated.

This happens with both AST 8.6.3 (used in DS9) and the latest 9.1.1. I haven't tested the latest master branch because it seems to require some Starlink versions of autotools stuff, which I'm no expert with generally, so it's not trivial to build.

*In our real-world example, I do actually see a small amount of variation in the 3rd World co-ordinate for very large pixel offsets from CRPIX2, but it remains almost constant for valid offsets, with the PermMap assigning that axis to a constant in the same way as above.

Am I right in thinking this is a bug / limitation, or are we doing something wrong here? Our FITS header seems valid to me.

Thanks!

James.

possible memory leaks detected by valgrind

Let's start with an empty "do-nothing" C program:

#include <stdlib.h>
#include <stdio.h>
#include <star/ast.h>

int main()
{
    return 0;
}

Compilation step: cc pkg-config --cflags cfitsio-I/home/chris/Downloads/wcssubs -o test_starlink test_starlink.c -L/usr/local/libast_link``
Valgrind command: valgrind --leak-check=full --show-leak-kinds=all --suppressions=/usr/share/glib-2.0/valgrind/glib.supp ./test_starlink
A clean output from valgrind:

chris@capricorn:~/projects/FITSWEBQLSE/tests> valgrind --leak-check=full --show-leak-kinds=all --suppressions=/usr/share/glib-2.0/valgrind/glib.supp ./test_starlink
==13866== Memcheck, a memory error detector
==13866== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==13866== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==13866== Command: ./test_starlink
==13866==
==13866==
==13866== HEAP SUMMARY:
==13866==     in use at exit: 0 bytes in 0 blocks
==13866==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==13866==
==13866== All heap blocks were freed -- no leaks are possible
==13866==
==13866== For lists of detected and suppressed errors, rerun with: -s
==13866== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Next let's add astBegin and andEnd with nothing else:

int main()
{
    astBegin;
    astEnd;

    return 0;
}

There are now "still reachable" blocks:

chris@capricorn:~/projects/FITSWEBQLSE/tests> valgrind --leak-check=full --show-leak-kinds=all --suppressions=/usr/share/glib-2.0/valgrind/glib.supp ./test_starlink
==13948== Memcheck, a memory error detector
==13948== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==13948== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==13948== Command: ./test_starlink
==13948==
==13948==
==13948== HEAP SUMMARY:
==13948==     in use at exit: 139,768 bytes in 3 blocks
==13948==   total heap usage: 4 allocs, 1 frees, 139,796 bytes allocated
==13948==
==13948== 16 bytes in 1 blocks are still reachable in loss record 1 of 3
==13948==    at 0x4845794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13948==    by 0x493F623: astGlobalsInit_ (globals.c:234)
==13948==    by 0x4BB1D94: astBegin_ (object.c:6601)
==13948==    by 0x401AEE: main (in /mnt/data/chris/projects/FITSWEBQLSE/tests/test_starlink)
==13948==
==13948== 32 bytes in 1 blocks are possibly lost in loss record 2 of 3
==13948==    at 0x484CC4C: realloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13948==    by 0x4B87B94: astRealloc_ (memory.c:3744)
==13948==    by 0x4BB1D41: astBegin_ (object.c:6620)
==13948==    by 0x401AEE: main (in /mnt/data/chris/projects/FITSWEBQLSE/tests/test_starlink)
==13948==
==13948== 139,720 bytes in 1 blocks are still reachable in loss record 3 of 3
==13948==    at 0x4845794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13948==    by 0x493F27F: astGlobalsInit_ (globals.c:138)
==13948==    by 0x4BB1D94: astBegin_ (object.c:6601)
==13948==    by 0x401AEE: main (in /mnt/data/chris/projects/FITSWEBQLSE/tests/test_starlink)
==13948==
==13948== LEAK SUMMARY:
==13948==    definitely lost: 0 bytes in 0 blocks
==13948==    indirectly lost: 0 bytes in 0 blocks
==13948==      possibly lost: 32 bytes in 1 blocks
==13948==    still reachable: 139,736 bytes in 2 blocks
==13948==         suppressed: 0 bytes in 0 blocks
==13948==
==13948== For lists of detected and suppressed errors, rerun with: -s
==13948== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

It gets progressively worse upon actually using AST to do something:

#include <stdlib.h>
#include <stdio.h>
#include <star/ast.h>

void test_fk5()
{
    double ra1, dec1, ra2, dec2;

    astBegin;

    AstSkyFrame *icrs = astSkyFrame("System=ICRS"); //,Epoch=2000,equinox=J2000");
    AstSkyFrame *fk5 = astSkyFrame("System=FK5");   //,Epoch=2000,equinox=J2000");

    AstFrameSet *icrs2fk5 = astConvert(icrs, fk5, " ");
    AstFrameSet *fk52icrs = astConvert(fk5, icrs, " ");

    // ds9 ra,dec in FK5
    ra1 = 52.2656215 * AST__DD2R;
    dec1 = 31.2677022 * AST__DD2R;

    printf("Original ra,dec (ds9) exported as FK5: %f %f\n", ra1 * AST__DR2D, dec1 * AST__DR2D);
    astTran2(fk52icrs, 1, &ra1, &dec1, 1, &ra2, &dec2);
    printf("AST FK5 --> ICRS: %f %f\n", ra2 * AST__DR2D, dec2 * AST__DR2D);

    printf("====================================================\n");

    // ds9 ra,dec in ICRS
    ra1 = 52.2656094 * AST__DD2R;
    dec1 = 31.2677078 * AST__DD2R;

    printf("Original ra,dec (ds9) exported as ICRS: %f %f\n", ra1 * AST__DR2D, dec1 * AST__DR2D);
    astTran2(icrs2fk5, 1, &ra1, &dec1, 1, &ra2, &dec2);
    printf("AST ICRS --> FK5: %f %f\n", ra2 * AST__DR2D, dec2 * AST__DR2D);

    // Clean up
    // not really needed as astEnd should do it
    astAnnul(icrs2fk5);
    astAnnul(fk52icrs);

    astAnnul(icrs);
    astAnnul(fk5);

    astEnd;
}

int main()
{
    astBegin;
    test_fk5();
    astEnd;

    return 0;
}

Valgrind reports plenty of memory errors. The list is rather long. What do you think? OS is 64-bit openSUSE Tumbleweed with gcc (SUSE Linux) 13.3.0.

(... prior entries omitted for brevity)
==14031== 240 bytes in 1 blocks are possibly lost in loss record 72 of 77
==14031==    at 0x4845794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==14031==    by 0x4B876AD: astMalloc_ (memory.c:2927)
==14031==    by 0x4BAFE44: astInitObject_ (object.c:5617)
==14031==    by 0x48A09F1: astInitAxis_ (axis.c:3215)
==14031==    by 0x48A0B61: astAxis_ (axis.c:3037)
==14031==    by 0x492570B: astInitFrame_ (frame.c:14921)
==14031==    by 0x4CF07C9: astInitTimeFrame_ (timeframe.c:7053)
==14031==    by 0x4CF0927: astTimeFrame_ (timeframe.c:6942)
==14031==    by 0x4CA8555: CalcLAST (skyframe.c:1294)
==14031==    by 0x4CAA010: SetLast.part.0 (skyframe.c:9340)
==14031==    by 0x4CAA072: SetLast (skyframe.c:9334)
==14031==    by 0x4CAA072: GetLAST (skyframe.c:3837)
==14031==    by 0x4CB2D93: MakeSkyMapping (skyframe.c:6065)
==14031==    by 0x4CB2D93: SubFrame (skyframe.c:10062)
==14031==
==14031== 240 bytes in 1 blocks are possibly lost in loss record 73 of 77
==14031==    at 0x4845794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==14031==    by 0x4B876AD: astMalloc_ (memory.c:2927)
==14031==    by 0x4BAFE44: astInitObject_ (object.c:5617)
==14031==    by 0x48A09F1: astInitAxis_ (axis.c:3215)
==14031==    by 0x48A0B61: astAxis_ (axis.c:3037)
==14031==    by 0x492570B: astInitFrame_ (frame.c:14921)
==14031==    by 0x4CF07C9: astInitTimeFrame_ (timeframe.c:7053)
==14031==    by 0x4CF0927: astTimeFrame_ (timeframe.c:6942)
==14031==    by 0x4CA856D: CalcLAST (skyframe.c:1295)
==14031==    by 0x4CAA010: SetLast.part.0 (skyframe.c:9340)
==14031==    by 0x4CAA072: SetLast (skyframe.c:9334)
==14031==    by 0x4CAA072: GetLAST (skyframe.c:3837)
==14031==    by 0x4CB2D93: MakeSkyMapping (skyframe.c:6065)
==14031==    by 0x4CB2D93: SubFrame (skyframe.c:10062)
==14031==
==14031== 248 bytes in 1 blocks are possibly lost in loss record 74 of 77
==14031==    at 0x484CC4C: realloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==14031==    by 0x4B87B94: astRealloc_ (memory.c:3744)
==14031==    by 0x4BB341F: astMakeId_ (object.c:7992)
==14031==    by 0x40162D: test_fk5 (in /mnt/data/chris/projects/FITSWEBQLSE/tests/test_starlink)
==14031==    by 0x401AF8: main (in /mnt/data/chris/projects/FITSWEBQLSE/tests/test_starlink)
==14031==
==14031== 360 bytes in 1 blocks are possibly lost in loss record 75 of 77
==14031==    at 0x4845794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==14031==    by 0x4B876AD: astMalloc_ (memory.c:2927)
==14031==    by 0x4BAFE44: astInitObject_ (object.c:5617)
==14031==    by 0x4B456B9: astInitMapping_ (mapping.c:23894)
==14031==    by 0x49255F6: astInitFrame_ (frame.c:14879)
==14031==    by 0x4CF07C9: astInitTimeFrame_ (timeframe.c:7053)
==14031==    by 0x4CF0927: astTimeFrame_ (timeframe.c:6942)
==14031==    by 0x4CA8555: CalcLAST (skyframe.c:1294)
==14031==    by 0x4CAA010: SetLast.part.0 (skyframe.c:9340)
==14031==    by 0x4CAA072: SetLast (skyframe.c:9334)
==14031==    by 0x4CAA072: GetLAST (skyframe.c:3837)
==14031==    by 0x4CB2D93: MakeSkyMapping (skyframe.c:6065)
==14031==    by 0x4CB2D93: SubFrame (skyframe.c:10062)
==14031==    by 0x4929C15: Match (frame.c:7332)
==14031==
==14031== 360 bytes in 1 blocks are possibly lost in loss record 76 of 77
==14031==    at 0x4845794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==14031==    by 0x4B876AD: astMalloc_ (memory.c:2927)
==14031==    by 0x4BAFE44: astInitObject_ (object.c:5617)
==14031==    by 0x4B456B9: astInitMapping_ (mapping.c:23894)
==14031==    by 0x49255F6: astInitFrame_ (frame.c:14879)
==14031==    by 0x4CF07C9: astInitTimeFrame_ (timeframe.c:7053)
==14031==    by 0x4CF0927: astTimeFrame_ (timeframe.c:6942)
==14031==    by 0x4CA856D: CalcLAST (skyframe.c:1295)
==14031==    by 0x4CAA010: SetLast.part.0 (skyframe.c:9340)
==14031==    by 0x4CAA072: SetLast (skyframe.c:9334)
==14031==    by 0x4CAA072: GetLAST (skyframe.c:3837)
==14031==    by 0x4CB2D93: MakeSkyMapping (skyframe.c:6065)
==14031==    by 0x4CB2D93: SubFrame (skyframe.c:10062)
==14031==    by 0x4929C15: Match (frame.c:7332)
==14031==
==14031== 139,720 bytes in 1 blocks are still reachable in loss record 77 of 77
==14031==    at 0x4845794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==14031==    by 0x493F27F: astGlobalsInit_ (globals.c:138)
==14031==    by 0x4BB1D94: astBegin_ (object.c:6601)
==14031==    by 0x401AEE: main (in /mnt/data/chris/projects/FITSWEBQLSE/tests/test_starlink)
==14031==
==14031== LEAK SUMMARY:
==14031==    definitely lost: 0 bytes in 0 blocks
==14031==    indirectly lost: 0 bytes in 0 blocks
==14031==      possibly lost: 4,456 bytes in 75 blocks
==14031==    still reachable: 139,736 bytes in 2 blocks
==14031==         suppressed: 0 bytes in 0 blocks
==14031==
==14031== For lists of detected and suppressed errors, rerun with: -s
==14031== ERROR SUMMARY: 75 errors from 75 contexts (suppressed: 0 from 0)

v9.2.10 release tarball

There is a tag for v9.2.10, https://github.com/Starlink/ast/releases/tag/v9.2.10.
If this is meant to be officially released, can you please create a GH release and add a release tarball as a proper GH asset (as in 9.2.8, not as in 9.2.9)? This would simplify packaging, in particular given the fact that e a stock autoconf isn't enough.

Build with external wcslib

It would be helpful for the Fedora package to be able to build with an external wcslib. Thank you.

Don't write DATE-OBS, MJD-OBS

We've discovered that AST is writing an incorrect DATE-OBS and MJD-OBS to our FITS headers (we haven't told the FrameSet the epoch, so it's coming out as ~2000-01-01). The epoch of observation can be vague (e.g., coadds), and in any case we're tracking it using other mechanisms so we don't want AST clobbering our values or writing incorrect values.

Can we add an attribute to AST to disable writing of DATE-OBS and MJD-OBS? I'm happy to do the work if this is approved.