Add support for disabling Position-Independent Code (PIC) generation through the OCAMLPARAM environment variable. This change would make it possible to specify a "nopic" token which, when set, instructs the native code generator to emit position-dependent code independently of what was requested at the command line.

The rationale of this option is similar to the other flags already supported by OCAMLPARAM: Allow the user to force generation of position-dependent code without the need for modifying build system files or sources.

This patch was directly motivated by the need for making cross-compilation possible of the Mirage unikernel [1] to the "kFreeBSD" backend. This backend basically compiles Mirage (OCaml) programs into FreeBSD kernel modules, where certain expectations must be satisfied. One of those expectations is that the generated code must not be position-independent as the FreeBSD kernel dynamic loader (kld(4)) does not support ELF relocations of that type. Hence PIC generation has to be disabled globally for all the compiled code, regardless what the original upstream packages were instructed for. The "nodynlink" flag is also used in this case.

The attached patch implements this functionality by moving the `pic_code` variable to the `Clflags` module for both the AMD64 and the ARM native code generator backends, while it retains the default settings for both. I have tested it on FreeBSD/amd64, but it should work on the ARM platform and on other operating systems.

It would be more natural, I think, to use pic=0 and pic=1 to disable or disable position-independent code. Given the fact that the key-value-handling logic is already present in the OCAMLPARAM code, the current patch allows nopic=1 and nopic=0 to respectively disable and enable position-independent code (with "nopic" being a shortcut for "nopic=1"), which is a rather obscure interface. If people prefer using "nopic" to "pic=0", we could at least support both pic and nopic as keys as Damien suggests.

if you allow me to nitpick (no pun intended), this code would not scale to the addition of other architectures. We should pattern-match on Config.architecture, with at least a case for each architecture on which the option makes sense (having a catch-all pattern with the default value for the others is reasonable).

Is anyone willing to improve the patch on these two aspects? Given the non-stellar reaction time, I would assume that the original contributor pgj may not be willing to do the extra work. If nobody comes forward by the time of the release, I could do it myself.

Please find a revisited version attached. It is now adapted to the trunk version as of today and theoretically has also the requested changes. I tested it on FreeBSD/amd64, it builds and works for me. Sorry for the delay :-)