Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 Jan 2014 11:31:08 -0600
From:      Stephen Montgomery-Smith <stephen@missouri.edu>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        FreeBSD Ports <freebsd-ports@FreeBSD.org>
Subject:   Re: Problems with linking on FreeBSD-10
Message-ID:  <52EBDDDC.7000702@missouri.edu>
In-Reply-To: <20140131132504.GZ24664@kib.kiev.ua>
References:  <52EAEC1D.9040502@missouri.edu> <20140131132504.GZ24664@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
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=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
-L/usr/home/stephen/sage/work/sage-6.0/local/lib/
-Wl,-rpath=/usr/home/stephen/sage/work/sage-6.0/local/lib
-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
../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

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
-L/usr/home/stephen/sage/work/sage-6.0/local/lib/
-Wl,-rpath=/usr/home/stephen/sage/work/sage-6.0/local/lib
-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
>>
>> _______________________________________________
>> freebsd-ports@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52EBDDDC.7000702>