Hang on, softfloat should be installed through softfloat, right?

I think we will have to learn from other users whether this causes annoyance, namely as a result of overwriting libsoftfloat with the Spike verison. If so, we will need to rename this one. But we can cross that bridge when we come to it.

OK, since @jerryz123 and I had similar reactions, let's hold off on this one.

Also this change wasn't necessary for my flow to link with libriscv at the installed path. I'll need to check how this works

Spike's softfloat has its own augmentations, so we should avoid naming it the same as public softfloat.

We might want to namespace both of these libraries (e.g. libspike-riscv and libspike-softfloat). But let's give Jerry time to opine before we take further action.

Furthermore, I'm not sure that libspike-softfloat should actually be distinct from libspike-riscv. It seems like Spike-as-library should lump everything into something called libspike (or libriscv in Jerry's flow, or whatever). This might require more Makefile hacking, but it's better to figure that out now, rather than creating an ABI that we'll soon break.

As it turns out, the Softfloat repo provides no flow for installing libsoftfloat and its headers... only this repo does. Given that, I don't think there's any risk from installing libsoftfloat.a. This repo already installs all the softfloat headers, and the .so as well. Installing libriscv.a in addition to libriscv.so is also acceptable.

If someone were to untangle this mess properly, I think they should:

• Add a proper build flow to berkeley-softfloat-3. This build flow should install variants of Softfloat specialized for different architectures (libsoftfloat-x86, libsoftfloat-armvfp2, libsoftfloat-riscv, etc.)
• Excise all softfloat sources here, and add -lsoftfloat-riscv when linking.

I don't expect ^ to get done anytime soon, so this PR should be good as it stands. @mslijepc , you have a use case which requires the static libraries to be installed instead of the dynamic libs?