On Mon, 22 Mar 2021, yunqiang.su@xxxxxxxxxxxxx wrote: > > I don't know why Google choose not to have their runtime support library > > (the Go library) as a dynamic shared object 20-something years on, but it > > comes at a price. So you either have to relink (recompile) all the > affected > > applications like in the old days or find a feasible workaround. > > > > I also have no idea why (even hate). > While there do be some program languages created in recently years, prefer > static link. Hmm, lost wisdom, or an orchestrated effort? Or a false illusion that since we're virtually fully open source now, we can always rebuild the world? Well, indeed this is technically possible, but whether it is feasible is another matter. Your case serves as a counterexample. > > As I noted in the discussion the use of FR=0 would be acceptable for FPXX > > binaries as far as I am concerned for R2 through R5, but not the FRE mode > for > > R6. > > There will no FPXX for r6. All of (if not mistake) R6 O32 is FP64. > FRE here is only for compatible with pre-R6 objects. That doesn't seem like a good choice to me. While R6 programs are indeed best built as FP64, libraries are best built as FPXX, so that users can link or load with whatever binary modules they have, including pre-R6 ones. As much as we may dislike it sources will not always be available or rebuilding them may be beyond the capabilities of whoever has the binaries, so I think the system should be as permissive as possible. So you may end up with running code that is largely R6 (libraries), and partly pre-R6 (application code) that ends up linked as FPXX. And the kernel has to support it in the best way possible too and avoid slow emulation where not necessary e.g. in R6 libm code used in the FPXX arrangement, which the FRE mode will inevitably lead to. Maciej
