Patch for ocamlmklib

[Jerry James]

I would like to ask for your collective wisdom again.  Upstream has
provided OC_CFLAGS and OC_LDFLAGS as a way to set the default compiler
and linker flags for ocamlopt.  However, there is currently no way to
set the default linker flags for ocamlmklib.  Many OCaml stublibs in
Fedora are therefore not linked with the Fedora hardening flags.  I've
done some hacky things in some packages to relink the stublibs with
the correct flags, but it would be nice if ocamlmklib would use the
right flags out of the box.

I took a stab tonight at embedding OC_LDFLAGS in ocamlmklib.  It
doesn't seem very difficult.  Would one or two of you mind looking at
the attached patch and see what you think?  If it looks good, I will
try submitting it upstream.  Thank you,

[Richard W.M. Jones]

On Wed, Feb 16, 2022 at 08:00:54PM -0700, Jerry James wrote:
> I would like to ask for your collective wisdom again.  Upstream has
> provided OC_CFLAGS and OC_LDFLAGS as a way to set the default compiler
> and linker flags for ocamlopt.  However, there is currently no way to
> set the default linker flags for ocamlmklib.  Many OCaml stublibs in
> Fedora are therefore not linked with the Fedora hardening flags.  I've
> done some hacky things in some packages to relink the stublibs with
> the correct flags, but it would be nice if ocamlmklib would use the
> right flags out of the box.
>
> I took a stab tonight at embedding OC_LDFLAGS in ocamlmklib.  It
> doesn't seem very difficult.  Would one or two of you mind looking at
> the attached patch and see what you think?  If it looks good, I will
> try submitting it upstream.  Thank you,
> -- 
> Jerry James
> http://www.jamezone.org/
> diff --git a/configure.ac b/configure.ac
> index 4ca231065..47a42a957 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -111,6 +111,7 @@ AC_SUBST([oc_cflags])
>  AC_SUBST([oc_cppflags])
>  AC_SUBST([oc_ldflags])
>  AC_SUBST([oc_dll_ldflags])
> +AC_SUBST([MKLIB_LDFLAGS])
>  AC_SUBST([bytecclibs])
>  AC_SUBST([nativecclibs])
>  AC_SUBST([ocamlc_cflags])
> @@ -177,6 +178,7 @@ AC_CONFIG_FILES([stdlib/sys.ml])
>  AC_CONFIG_FILES([manual/src/version.tex])
>  AC_CONFIG_FILES([manual/src/html_processing/src/common.ml])
>  AC_CONFIG_FILES([tools/eventlog_metadata])
> +AC_CONFIG_FILES([tools/ocamlmklib.ml])
>  AC_CONFIG_HEADERS([runtime/caml/m.h])
>  AC_CONFIG_HEADERS([runtime/caml/s.h])
>  AC_CONFIG_HEADERS([runtime/caml/version.h])
> @@ -975,6 +977,10 @@ AS_IF([test x"$enable_shared" != "xno"],
>
> AS_IF([test -z "$mkmaindll"], [mkmaindll=$mksharedlib])
>
> +AS_IF([test -z "$OC_LDFLAGS"],
>  [MKLIB_LDFLAGS=""],
>  [MKLIB_LDFLAGS="\"$OC_LDFLAGS\""])
>
> # Configure native dynlink
>
> natdynlink=false
> diff --git a/tools/ocamlmklib.ml.in b/tools/ocamlmklib.ml.in
> index 0ca7b80f3..80c6c7515 100644
> --- a/tools/ocamlmklib.ml.in
> +++ b/tools/ocamlmklib.ml.in
> @@ -46,7 +46,7 @@ and failsafe = ref false    (* whether to fall back on static build only *)
>  and c_libs = ref []         (* libs to pass to mksharedlib and ocamlc -cclib *)
>  and c_Lopts = ref []      (* options to pass to mksharedlib and ocamlc -cclib *)
>  and c_opts = ref []       (* options to pass to mksharedlib and ocamlc -ccopt *)
> -and ld_opts = ref []        (* options to pass only to the linker *)
> +and ld_opts = ref [@MKLIB_LDFLAGS@] (* options to pass only to the linker *)
>  and ocamlc = ref (compiler_path "ocamlc")
>  and ocamlc_opts = ref []    (* options to pass only to ocamlc *)
>  and ocamlopt = ref (compiler_path "ocamlopt")

It kind of seems OK, but wouldn't it be best to do this as a pull
request against github.com/ocaml/ocaml ?  They will know a lot more
about the build system quirks.

Rich.

[Jerry James]

On Thu, Feb 17, 2022 at 5:07 AM Richard W.M. Jones  wrote:
> On Wed, Feb 16, 2022 at 08:00:54PM -0700, Jerry James wrote:
> > I took a stab tonight at embedding OC_LDFLAGS in ocamlmklib.  It
> > doesn't seem very difficult.  Would one or two of you mind looking at
> > the attached patch and see what you think?  If it looks good, I will
> > try submitting it upstream.  Thank you,
>
> It kind of seems OK, but wouldn't it be best to do this as a pull
> request against github.com/ocaml/ocaml ?  They will know a lot more
> about the build system quirks.

Yes, that's what I said I would do in the paragraph above.  I was just
hoping somebody would tell me if I was way out in left field.  I'll
take it upstream.