Hi! On Fri, 13 Sep 2013 15:29:30 +0400, "Michael V. Zolotukhin" <michael.v.zolotuk...@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
pgp0x_Eqo0MfP.pgp
Description: PGP signature