[RFC] Offloading Support in libgomp

[Thomas Schwinge]

Hi!

On Fri, 13 Sep 2013 15:29:30 +0400, "Michael V. Zolotukhin" <michael.v.zolotukhin@gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20140717/7c418975/attachment.sig>