Solved - was: Problems with linking on FreeBSD-10
stephen at missouri.edu
Tue Feb 4 21:38:52 UTC 2014
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
>>> 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=path-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.
> Here are more details. I have the -L there as well.
> It creates libR.so using a command
> like this:
> cc -std=gnu99 -shared -fopenmp
> -Wl,-rpath=/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
> -L/usr/home/stephen/sage/work/sage-6.0/local/lib -lf77blas -latlas
> -lgfortran -lm -lquadmath -lintl -lreadline -llzma -lrt -lm -liconv
> 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:
> gcc -std=gnu99 -export-dynamic -fopenmp
> -Wl,-rpath=/usr/local/lib/gcc46 -L/usr/local/lib/gcc46 -o R.bin Rmain.o
> -L../../lib -lR
> ...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.
>>> Unfortunately the libR.so pulls in /lib/libreadline - the version that
>>> comes with the base FreeBSD. I thought that -rpath flag was supposed to
>>> 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 <path> 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 extra
>>> 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
libreadline.so.6. But for ld to work, it also had to contain a link
(Is this sort of behavior documented anywhere?)
More information about the freebsd-ports