Silo has a smaller tarball for 4.7 now available for your use. Here is a smaller silo-4.7-smalltest.tar.gz tarball to use.
Obtain source code here: https://wci.llnl.gov/content/assets/docs/simulation/computer-codes/silo/silo-4.7/silo-4.7.tar.gz
Obtain documentation here: https://wci.llnl.gov/content/assets/docs/simulation/computer-codes/silo/LLNL-SM-410226.pdf
First, have no fear, if you REALLY DON'T WANT TO DEAL WITH THIS, then just make sure you configure Silo with --enable-legacy-datatyped-pointers.
It has been a source of confusion to many users of Silo for many years that functions like DBPutUcdmesh accept an 'int datatype' argument to specify the datatype of the coordinate arrays but than the coordinate arrays themselves are specified as 'float *coords' in the API. Users either discovered on their own or asked Silo developers if it is OK to pass pointers to arrays other than float. Indeed, it has been. The same has also been true of the struct objects that Silo returns in its read interface. For example a DBucdmesh object contains an 'int datatype' member to indicate the datatype of the 'coords' member. However, the coords member type was still float* leading to still other confusion when trying to read Silo data. This problem has existed throughout most of the older functions and objects of Silo's API but has been avoided with newer functions and objects by appropriate use of 'void*'. Nonetheless, this behavior for older functions and objects has often led to questions that would have to be fielded by Silo developers.
Starting in version 4.7, all these cases have been 'modernized' to use 'void *'. But, this can be controlled during configuration of the Silo library using the --enable-legacy-datatyped-pointers. This way, if you are comfortable using the old (legacy) conventions, you are free to continue doing so. Support for this will never be removed from the Silo library. However, new users of Silo will most likely compile Silo without this option and experience a less confusing interface. Regardless, the Silo User's manual documents only the modernized interface.
Note that the effect of these API changes are confined primarily to the read half of Silo's interface. So, if you are simply writing Silo files but not reading them, you should experience no errors. Furthermore, on the read half of the interface, the issues you will encounter are compiler errors when you access a void* data member of a Silo object without properly casting it to the desired type, which is specified by an associated 'int datatype' member of the object. Also, since any application reading double precision data would have had to deal with this already to avoid compiler warnings in assigning float* to double*, and since those warnings will become outright errors, the cases that need any attention to be made compliant with the modernized API should be obvious and easily corrected.
Silo 4.7 is NOT link-time compatible with any previous versions. To use it, you will need to re-compile any Silo client code.