This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Offloading Support in libgomp


On Fri, 13 Sep 2013 15:29:30 +0400, "Michael V. Zolotukhin" <> 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.)


Attachment: pgpsi7PPRWu20.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]