starlink / ast Goto Github PK
View Code? Open in Web Editor NEWStarlink AST Library
License: GNU Lesser General Public License v3.0
Starlink AST Library
License: GNU Lesser General Public License v3.0
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 or % export STARCONF_DEFAULT_STARLINK=/local-star # sh % export STARCONF_DEFAULT_PREFIX=/local-star - Delete any previous Starlink environment variables. % unsetenv INSTALL # csh % unsetenv STARLINK or % 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 or # 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 or % 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
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:
I'm a big fan of this library and would like to see its visibility increase. Thanks to all for the work on it!
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/lib
ast_link -pthread
AST has been configured / compiled with ./configure --prefix=/usr/local --with-memdebug
Test source code: test_starlink.c
test_starlink.c.txt
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:
void*
pointer is only allowed in GCC (See https://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c)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?
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.
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?
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
?
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.
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.
I'm working on changing the Fedora ast package to build with an external pal lib. However, I'm running into a couple issues:
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
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
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.
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!
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.
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/lib
ast_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)
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.
It would be helpful for the Fedora package to be able to build with an external wcslib. Thank you.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.