From owner-freebsd-ports@FreeBSD.ORG Tue Feb 4 21:38:52 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7581E7FC for ; Tue, 4 Feb 2014 21:38:52 +0000 (UTC) Received: from mst-rip5-missouri-out.um.umsystem.edu (mst-rip5-missouri-out.um.umsystem.edu [198.209.50.135]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF4171E09 for ; Tue, 4 Feb 2014 21:38:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAE9d8VLPoJ7S/2dsb2JhbABZgww4V74cgQ8WdIIlAQEFJ00EARACARYKCRYPCQMCAQIBICUCBA0BBwEBiAHFbYg3F451B4Q4BIkRkEyQb4Mtgio X-IPAS-Result: Ag0FAE9d8VLPoJ7S/2dsb2JhbABZgww4V74cgQ8WdIIlAQEFJ00EARACARYKCRYPCQMCAQIBICUCBA0BBwEBiAHFbYg3F451B4Q4BIkRkEyQb4Mtgio Received: from um-ncas5.um.umsystem.edu ([207.160.158.210]) by mst-rip5-exch-relay.um.umsystem.edu with ESMTP; 04 Feb 2014 15:38:45 -0600 Received: from UM-MBX-N02.um.umsystem.edu ([169.254.5.41]) by UM-NCAS5.um.umsystem.edu ([207.160.158.210]) with mapi id 14.03.0174.001; Tue, 4 Feb 2014 15:38:43 -0600 From: "Montgomery-Smith, Stephen" To: Konstantin Belousov Subject: Solved - was: Problems with linking on FreeBSD-10 Thread-Topic: Solved - was: Problems with linking on FreeBSD-10 Thread-Index: AQHPHholgD2MMQMMlEanesmM2H1EvZqfOBQAgABEwACABo51AA== Date: Tue, 4 Feb 2014 21:38:42 +0000 Message-ID: <52F15DDA.3000101@missouri.edu> References: <52EAEC1D.9040502@missouri.edu> <20140131132504.GZ24664@kib.kiev.ua> <52EBDDDC.7000702@missouri.edu> In-Reply-To: <52EBDDDC.7000702@missouri.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 x-originating-ip: [207.160.158.206] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: FreeBSD Ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 21:38:52 -0000 On 01/31/2014 11:31 AM, Stephen Montgomery-Smith wrote: > On 01/31/14 07:25, Konstantin Belousov wrote: >> On Fri, Jan 31, 2014 at 12:19:46AM +0000, Montgomery-Smith, Stephen >> wrote: >>> I maintain the port math/sage. The port builds its own version of the >>> libreadline library. The port also uses lang/gcc instead of clang, >>> because the port needs Fortran. >>> >>> The port is wanting to create a shared library called libR.so, which it >>> wants to link with the libreadline library it created itself. So it >>> issues this kind of command: >>> >>> gcc46 -Wl,-rpath=3Dpath-of-newly-made-library -o libR.so -lreadline >>> >>> I have left out most of the command for brevity. >> Not for brevity, but to make the diagnostic impossible. >> >=20 > Here are more details. I have the -L there as well. >=20 > It creates libR.so using a command > like this: >=20 > cc -std=3Dgnu99 -shared -fopenmp > -L/usr/home/stephen/sage/work/sage-6.0/local/lib/ > -Wl,-rpath=3D/usr/home/stephen/sage/work/sage-6.0/local/lib > -Wl,-rpath=3D/usr/local/lib/gcc46 -L/usr/local/lib/gcc46 -o libR.so > CommandLineArgs.o Rdynload.o Renviron.o RNG.o agrep.o apply.o > arithmetic.o array.o attrib.o bind.o builtin.o character.o coerce.o > colors.o complex.o connections.o context.o cum.o dcf.o datetime.o > debug.o deparse.o devices.o dotcode.o dounzip.o dstruct.o duplicate.o > edit.o engine.o envir.o errors.o eval.o format.o gevents.o gram.o > gram-ex.o graphics.o grep.o identical.o inlined.o inspect.o internet.o > iosupport.o lapack.o list.o localecharset.o logic.o main.o mapply.o > match.o memory.o names.o objects.o options.o paste.o platform.o plot.o > plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o > qsort.o random.o raw.o registration.o relop.o rlocale.o saveload.o > scan.o seq.o serialize.o sort.o source.o split.o sprintf.o startup.o > subassign.o subscript.o subset.o summary.o sysutils.o unique.o util.o > version.o vfonts.o xxxpr.o `ls ../unix/*.o ../appl/*.o ../nmath/*.o` > ../extra/zlib/libz.a ../extra/bzip2/libbz2.a ../extra/pcre/libpcre.a > ../extra/tre/libtre.a > -L/usr/home/stephen/sage/work/sage-6.0/local/lib -lf77blas -latlas > -lgfortran -lm -lquadmath -lintl -lreadline -llzma -lrt -lm -liconv >=20 > Now -Wl,-rpath is set, so it should find libreadline in > /usr/home/stephen/sage/work/sage-6.0/local/lib. But instead it finds > libreadline in /lib. So later when it does the following compilation to > build R.bin: >=20 > gcc -std=3Dgnu99 -export-dynamic -fopenmp > -L/usr/home/stephen/sage/work/sage-6.0/local/lib/ > -Wl,-rpath=3D/usr/home/stephen/sage/work/sage-6.0/local/lib > -Wl,-rpath=3D/usr/local/lib/gcc46 -L/usr/local/lib/gcc46 -o R.bin Rmain.o > -L../../lib -lR >=20 > ...it comes up with an error saying that rl_sort_completion_matches > isn't found. And when I do an ldd or "readelf -d" on libR.so, I can see > that it is trying to link to the wrong libreadline, and > rl_sort_completion_matches is only defined in the other libreadline. >=20 >=20 >>> >>> Unfortunately the libR.so pulls in /lib/libreadline - the version that >>> comes with the base FreeBSD. I thought that -rpath flag was supposed t= o >>> tell the linker where to find the library. But it doesn't. >> Show exact commands and exact error message. It is not possible to >> understand from you message is the failure at the static linking (ld(1)) >> or dynamic (at the program startup) stage. >> >> Just in case this might be useful: >> - -rpath only affects runtime search path >> - ld(1) search for libraries is directed with the -L option. >> >>> >>> The failure is when using FreeBSD-10. With FreeBSD-8 it works great. = I >>> also assume that gcc46 uses /usr/local/bin/ld instead of /usr/bin/ld, >>> since devel/binutils is a dependency of lang/gcc. >>> >>> Can anyone help me? Is this a bug with FreeBSD? Or is there some extr= a >>> flag I can set with the linker to make it work? I have tried >>> -rpath-link and -z origin, but these were random guesses. and I don't >>> really know what I am doing. >>> >>> Thanks, Stephen /usr/home/stephen/sage/work/sage-6.0/local/lib contained libreadline.so.6. But for ld to work, it also had to contain a link libreadline.so->libreadline.so.6. (Is this sort of behavior documented anywhere?)