Date: Wed, 25 Jun 2014 11:50:29 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: FreeBSD Ports ML <freebsd-ports@freebsd.org> Subject: rpath issues with a port Message-ID: <CAN6yY1v0ZZsVHwGpEcP-Hc4dMnN2P%2BQ2FSV9ePU3CimHoWuSDw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
editors/emacs currently fails on most 10.0 systems because it links to libgomp.so. The problem is that the base system contains a stub library for this in /usr/lib with the real library being installed as a port of he gcc ports in /usr/local/lib. the problem I see is that configuring fails when the a test for gtk tries to link to that library, but fails to find several symbols that, of course, are not in the stub, but just the real library. The test in configure includes "-rpath=/usr/lib:/usr/local/lib and, since libgomp.so is present on he first path, that one is used and the configure fails. The error occurs when attempting to pull in a couple of libraries from Imagemagick which builds just fine while linking directly to libgomp.so, while emacs fails when attempting to link to the Imagemagick libraries that are linked to it. I have very little experience with autotools. I have spend time looking at configure.in and configure.ac, but have failed to figure out how the rpath option is generates or how to reverse the order of the path for libgomp. Can anyone give my a clue as to how this works? Since there are a number of stub libs in the system, I assume that this is not a problem unique to this port. N.B. Ihave succeeded in updating emacs on my system by moving the base version of libgomp aside during the build, so I am looking for how to deal with the generic problem, not this specific instance. A bug (191193) is open with additional details on the emacs failure. Thanks, -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1v0ZZsVHwGpEcP-Hc4dMnN2P%2BQ2FSV9ePU3CimHoWuSDw>