Hi! On Fri, 13 Sep 2013 15:29:30 +0400, "Michael V. Zolotukhin" <[email protected]> wrote: > [patch for adding plugins support in libgomp]
One question:
> --- a/libgomp/target.c
> +++ b/libgomp/target.c
> +/* This functions scans folder, specified in environment variable
> + LIBGOMP_PLUGIN_PATH, and loads all suitable libgomp plugins from this
> folder.
> + For a plugin to be suitable, its name should be "libgomp-plugin-*.so.1"
> and
> + it should implement a certain set of functions.
> + Result of this function is properly initialized variable NUM_DEVICES and
> + array DEVICES, containing all plugins and their callback handles. */
> +static void
> +gomp_find_available_plugins (void)
> +{
> + char *plugin_path = NULL;
> +[...]
> + plugin_path = getenv ("LIBGOMP_PLUGIN_PATH");
What is the benefit of making this an environment variable that the user
set to set, LIBGOMP_PLUGIN_PATH, as opposed to hard-coding it to
somewhere inside the GCC installation directory ([...]/lib/libgomp/*.so)?
(There, it can still be overridden; dlopen obeys DT_RPATH/DT_RUNPATH, and
LD_LIBRARY_PATH.) Hard-coding it would make libgomp testing a bit
easier, and it generally seems to make sense to me that the compiler
(libgomp) should be able to locate its own resources, and I don't think
the plugin search path is something that a user generally would want to
override -- or is your use case indeed that the plugin is not built as
part of libgomp's build process? (But, in this case you still could use
LD_LIBRARY_PATH to have it found.)
Grüße,
Thomas
pgp0x_Eqo0MfP.pgp
Description: PGP signature
