Hi! First, thanks for improving portability of the libgomp plugin interface!
On Wed, 28 Jan 2015 16:43:19 -0500, Jack Howarth <howarth.at....@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
pgpvDo36_jNAl.pgp
Description: PGP signature
