[PATCH] PR64635 - load libgomp-plugin-host_nonshm shared library with correct suffix

Thomas Schwinge thomas@codesourcery.com
Thu Jan 29 08:13:00 GMT 2015


Hi!

First, thanks for improving portability of the libgomp plugin interface!


On Wed, 28 Jan 2015 16:43:19 -0500, Jack Howarth <howarth.at.gcc@gmail.com> wrote:
> There is one other issue that I have been
> pondering about filing a PR. In fink and MacPorts, FSF gcc is built
> and packaged using either...
> 
> --prefix=/sw/lib/gcc5.0
> 
> or
> 
> --libdir=/opt/local/lib/gcc5
> 
> such that the libraries for each gcc release are buried. While this
> doesn't present an issue in running the libgomp test suite when
> -DACC_DEVICE_TYPE_host_nonshm=1 is used

(Note that the host_nonshm device type/plugin is probably not something
end users would really use -- other than for debugging if no more
suitable offloading device is available -- but the problem of course is a
general one.)

> end-users will have to
> explicitly set DYLD_LIBRARY_PATH to contain /sw/lib/gcc5.0/lib or
> /opt/local/lib/gcc5 for such executables to find the
> libgomp-plugin-host_nonshm shared library.
>      I realize this is a corner case, but shouldn't libgomp/target.c
> contain a hard-coded path from the build for the location of the
> installed gcc libraries and make an initial attempt to open it from
> that location before attempting a second time without an explicit
> path? Any thoughts?

This has been discussed before in
<http://news.gmane.org/find-root.php?message_id=%3C87egxknjay.fsf%40kepler.schwinge.homeip.net%3E>
and the messages before that one.  A GCC installation tree has to be
relocatable, so in my understanding it is not appropriate to hard-code
absolute (build-time) paths.  My idea was that a system's dynamic linker
already has to locate the libgomp shared object (on a GNU/Linux system
through LD_LIBRARY_PATH, or -Wl,-rpath,[...], for example), and via the
same lookup mechanism the libgomp plugins should be found.  Does that
scheme not generally work?  That'd be a pity indeed...  :-/


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: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20150129/47e9ddd5/attachment.sig>


More information about the Gcc-patches mailing list