This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Offloading Support in libgomp
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Ilya Verbin <iverbin at gmail dot com>
- Cc: Thomas Schwinge <thomas at codesourcery dot com>, Kirill Yukhin <kirill dot yukhin at gmail dot com>, Richard Henderson <rth at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>, triegel at redhat dot com, julian at codesourcery dot com
- Date: Thu, 17 Jul 2014 14:37:12 +0200
- Subject: Re: [RFC] Offloading Support in libgomp
- Authentication-results: sourceware.org; auth=none
- References: <20130827115538 dot GB4093 at msticlxl57 dot ims dot intel dot com> <20130828093428 dot GO21876 at tucnak dot zalov dot cz> <20130910150126 dot GA2059 at msticlxl57 dot ims dot intel dot com> <20130910151453 dot GB1817 at tucnak dot redhat dot com> <20130910153053 dot GB2059 at msticlxl57 dot ims dot intel dot com> <20130910153624 dot GD1817 at tucnak dot redhat dot com> <20130910153810 dot GC2059 at msticlxl57 dot ims dot intel dot com> <20130913112930 dot GC30181 at msticlxl57 dot ims dot intel dot com> <87tx6go21t dot fsf at kepler dot schwinge dot homeip dot net> <CADG=Z0FrJdByBEqVHBdFfDBpV+aUrSr9ExeLPpyKdqK=EoTyNg at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Jul 17, 2014 at 04:30:15PM +0400, Ilya Verbin wrote:
> 2014-07-17 11:51 GMT+04:00 Thomas Schwinge <thomas@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, 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.
Jakub