On Fri, Aug 18, 2023 at 09:10:32AM -0500, Eric Blake wrote:
On Fri, Aug 18, 2023 at 08:27:45AM -0500, Eric Blake wrote:
> In
https://gitlab.com/nbdkit/nbdkit/-/merge_requests/30, Khem reports
> that in a cross-compilation environment, nbdkit embeds the absolute
> name of the cross-compiler into the resulting cc plugin, even though
> running the plugin should be favoring the bare name 'cc'. This in
> turn leads to non-reproducible builds. As the goal of cross-compiling
> nbdkit is to produce a binary that behaves identically regardless of
> the build environment used, this means we need to give the user
> control over the defaults for CC and CFLAGS embedded into the cc
> plugin.
>
> However, instead of trying to munge the build environment variable as
> suggested in that merge request, I found it cleaner to just add
> additional precious variables to be set at configure time, as in:
>
> ./configure CC=/path/to/cross-compiler CC_PLUGIN_CC='ccache gcc' ...
>
> Reported-by: Khem Raj
> Signed-off-by: Eric Blake <eblake(a)redhat.com>
Do we need 'Fixes:' here with the link to the merge request?
> ---
>
> gitlab doesn't let me see the right email address to cc; if I can
> figure that out, I'll tweak the Reported-by line as appropriate before
> committing...
> ---
> plugins/cc/nbdkit-cc-plugin.pod | 9 ++++++---
> configure.ac | 11 +++++++++++
> plugins/cc/Makefile.am | 4 ++--
> 3 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/plugins/cc/nbdkit-cc-plugin.pod b/plugins/cc/nbdkit-cc-plugin.pod
> index 2974890c..2bc3cfb8 100644
> --- a/plugins/cc/nbdkit-cc-plugin.pod
> +++ b/plugins/cc/nbdkit-cc-plugin.pod
> @@ -45,9 +45,12 @@ To replace the compiler flags:
>
> The plugin parameters C<CC>, C<CFLAGS> and C<EXTRA_CFLAGS>
(written in
> uppercase) can be used to control which C compiler and C compiler
> -flags are used. If not set, the default compiler and flags from when
> -nbdkit was itself compiled from source are used. To see what those
> -were you can do:
> +flags are used. If not set, you can hardcode the defaults for C<CC>
> +and C<CFLAGS> at the time nbdkit is compiled from source by
> +configuring with C<CC_PLUGIN_CC=...> and C<CC_PLUGIN_CFLAGS=...>,
> +otherwise, the configuration for compiling nbdkit itself is used
> +(C<EXTRA_CFLAGS> can only be set from the command line when starting
> +the cc plugin). To see what those were you can do:
>
> $ nbdkit cc --dump-plugin
> ...
Widening the context,
...
CC=gcc
CFLAGS=-g -O2 -fPIC -shared
The C<CFLAGS> parameter overrides the built-in flags completely. The
C<EXTRA_CFLAGS> parameter adds extra flags to the built-in flags.
Since we already mention EXTRA_CFLAGS below the example, I'm not sure
if my addition of a parenthetical about EXTRA_CFLAGS above is
worthwhile, or just adds noise.
TBH I would just leave the documentation as it is now. The user of
the plugin doesn't care that there was a ./configure flag that the
downstream packager could have used.
> diff --git a/configure.ac b/configure.ac
> index afc5ddab..e5e261c8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -820,6 +820,15 @@ AC_ARG_ENABLE([plugins],
> [disable all bundled plugins and filters])])
> AM_CONDITIONAL([HAVE_PLUGINS], [test "x$enable_plugins" !=
"xno"])
>
> +dnl For the cc plugin, let the user hard-code their preferred compiler setup
> +dnl Default to the settings used for nbdkit itself
> +AC_ARG_VAR([CC_PLUGIN_CC],
> + [Value to use for CC when building the cc plugin, default $CC])
I'm wondering if there is a better way to word this (it shows up in
'./configure --help' output). Maybe:
[Value to hard-code into the cc plugin's default for CC, instead of $CC]
This seems better. Does $CC expand here? It might actally be better
if it appears as literal "$CC".
> +: "${CC_PLUGIN_CC:=$CC}"
> +AC_ARG_VAR([CC_PLUGIN_CFLAGS],
> + [Value to use for CFLAGS when building the cc plugin, default $CFLAGS])
> +: "${CC_PLUGIN_CFLAGS:=$CFLAGS}"
and similar
Reviewed-by: Richard W.M. Jones <rjones(a)redhat.com>
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages.
http://libguestfs.org