Solved - was: Problems with linking on FreeBSD-10
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 +, 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 /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?) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Solved - was: Problems with linking on FreeBSD-10
On 2014-Feb-04 21:38:42 +, Montgomery-Smith, Stephen step...@missouri.edu wrote: /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?) I think it's sort-of communal mind knowlegde rather than being specifically written down: If the loader sees '-lfoo', it looks for libfoo.so or libfoo.a in locations specified by -L. If it finds libfoo.so then it will read at internal name out of it (eg libfoo.so.5) and store that in the executable. The rtld will then look for libfoo.so.5 using -rpath locations. ISTR having to manually craft some libfoo.so - libfoo.so.N during my sage porting efforts. The sage build process knows far too much about toolchain innards. -- Peter Jeremy pgpSY8kvxqcxr.pgp Description: PGP signature
Re: Problems with linking on FreeBSD-10
On Fri, Jan 31, 2014 at 12:19:46AM +, 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. 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-unsubscr...@freebsd.org pgpBG4HKMt2lM.pgp Description: PGP signature
Re: Problems with linking on FreeBSD-10
The failure is when using FreeBSD-10. With FreeBSD-8 it works great. I Building ports on 10.0-RELEASE is lots more trouble than 9.2-RELEASE. 10.0-RELEASE built 874, 9.2-RELEASE built 953 still making, with http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/ports/jhs/*/Makefile.local cd /usr/ports/packages/All ; /bin/ls -1 | wc -l 10.0-RELEASE has 40 DUDS, 9.2-RELEASE has 7 DUDS so far in http://www.berklix.com/~jhs/src/bsd/fixes/freebsd/src/jhs/etc/csh.cshrc.master Lot of broken ports in 10.0-RELEASE are cc errors, (Clang, 9.2 was gcc). Some are Stage failures. New tools breaking, typical of a .0 release. I was tempted to 10 by man urtwn (4) (WLAN), but then 10 src/ ripped out bind, 10.0 ports wasted time to delivered less. 9.2-RELEASE is better. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Interleave replies below like a play script. Indent old text with . Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Problems with linking on FreeBSD-10
On 01/31/14 07:25, Konstantin Belousov wrote: On Fri, Jan 31, 2014 at 12:19:46AM +, 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-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
