Hi!
On Thu, 17 Jul 2014 14:37:12 +0200, Jakub Jelinek <ja...@redhat.com> wrote:
> On Thu, Jul 17, 2014 at 04:30:15PM +0400, Ilya Verbin wrote:
> > 2014-07-17 11:51 GMT+04:00 Thomas Schwinge <tho...@codesourcery.com>:
> > >> + 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.)
> >
> > We invented this environment variable almost a year ago, when we
> > didn’t fully understand how all the parts will work together. So for
> > now, likely, your proposal is better.
> > Jakub, what do you think?
>
> Yeah, certainly. Though, ideally the path it looks at should be relative
> to the directory where libgomp is installed
Right...
> and I'm afraid it is hard to
> figure out portably where it was loaded from, and DT_RPATH/DT_RUNPATH on
> libgomp would affect all dlopen calls, not just the loading of the plugins.
> Not sure if one can use at least on Linux ${ORIGIN} in dlopen and what
> exactly will it expand to.
I haven't verified, but I'd guess it to expand to the *executable*
linking against libgomp, so that won't help...
I have, however, found some logic in gcc/plugin.c that seems at least
similar to what we need:
gcc/doc/plugins.texi:
@node Plugins loading
@section Loading Plugins
Plugins are supported on platforms that support @option{-ldl
-rdynamic}. They are loaded by the compiler using @code{dlopen}
and invoked at pre-determined locations in the compilation
process.
Plugins are loaded with
@option{-fplugin=/path/to/@var{name}.so} [...]
[...]
A plugin can be simply given by its short name (no dots or
slashes). When simply passing @option{-fplugin=@var{name}}, the plugin is
loaded from the @file{plugin} directory, so @option{-fplugin=@var{name}} is
the same as @option{-fplugin=`gcc -print-file-name=plugin`/@var{name}.so},
using backquote shell syntax to query the @file{plugin} directory.
gcc/plugin.c:
/* Retrieve the default plugin directory. The gcc driver should have passed
it as -iplugindir <dir> to the cc1 program, and it is queriable through
the
-print-file-name=plugin option to gcc. */
const char*
default_plugin_dir_name (void)
{
if (!plugindir_string)
fatal_error ("-iplugindir <dir> option not passed from the gcc driver");
return plugindir_string;
}
But I'm not yet sure how we could use this to tie the libgomp plugin
search path to the location of libgomp.so... Especially, given that the
location of libgomp.so during compilation need not match the location
during execution. A show-stopper? (No time currently to explore this in
more detail.)
Grüße,
Thomas
pgpM1fisFTYnW.pgp
Description: PGP signature
