decide whether to install binutils into existing jaspy/3.8/r20211105 environment

[alaniwi]

There is some breakage in jaspy/3.8/r20211105 environment due to the absence of symlinks for ld etc. (See https://github.com/cedadev/ceda-jaspy-envs/issues/90 regarding fixing this for the future.)

Example - the system ld does not work with object files created using the Jaspy gcc where -g has been used, whereas the Jaspy ld is fine but not picked up by just typing ld.

$ module list jaspy
Currently Loaded Modulefiles:
  1) jaspy/3.8/r20211105

$ which gcc
/apps/jasmin/jaspy/miniconda_envs/jaspy3.8/m3-4.9.2/envs/jaspy3.8-m3-4.9.2-r20211105/bin/gcc

$ which ld
/usr/bin/ld

$ cat foo.c
void foo() {}

$ gcc -c -g foo.c

$ ld -shared -o foo.so foo.o
ld: foo.o: unable to initialize decompress status for section .debug_info
ld: foo.o: unable to initialize decompress status for section .debug_info
foo.o: file not recognized: File format not recognized

$ ls -l `which gcc`
lrwxrwxrwx 1 root root 26 Oct 29 09:24 /apps/jasmin/jaspy/miniconda_envs/jaspy3.8/m3-4.9.2/envs/jaspy3.8-m3-4.9.2-r20211105/bin/gcc -> x86_64-conda-linux-gnu-gcc

$ $CONDA_PREFIX/bin/x86_64-conda-linux-gnu-ld -shared -o foo.so foo.o

$

So there is a question whether to fix this in the existing environment (perhaps breaking promises about reproducibility), or to wait for the next Jaspy release.

Installing the "binutils" package would provide the symlinks in question.

[alaniwi]

Note: I have already fixed the cf-python package by adding a shared library needed to open PP files, which failed to build during the initial installation, as the existing behaviour was not working at all (could not open PP files) so would not need to be reproduced, whereas regarding picking up the wrong version of ld etc for other purposes, this could still sort of work in some circumstances even if not fully as intended.

[alaniwi]

As we are close to providing a new environment, let's not modify the existing one.