[kde-freebsd] [Bug 208120] devel/cmake strips necessary rpath when installing any gnu compiler from ports

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sun Apr 3 11:56:42 UTC 2016


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120

--- Comment #7 from Raphael Kubo da Costa <rakuco at FreeBSD.org> ---
Created attachment 168925
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=168925&action=edit
Self-contained fortran+CMake example

To me, CMake does not seem to be doing anything wrong or unusual here.

lang/gcc's pkg-message says:
> To ensure binaries built with this toolchain find appropriate versions
> of the necessary run-time libraries, you may want to link using
>
>  -Wl,-rpath=/usr/local/lib/gcc48
>
> For ports leveraging USE_GCC, USES=compiler, or USES=fortran this happens
> transparently.
Indeed, if I just do `gcc48 hello.c' I get a binary that depends (via
DT_NEEDED) on libstdc++.so.6 and libgcc_so.1 (among other libraries) but with
no RPATH. And obviously I pass -Wl,rpath=/usr/local/lib/gcc48 I get a binary
that depends on those two libraries and has a DT_RPATH entry set to
/usr/local/lib/gcc48 (and ldd shows that both libstdc++.so.6 and libgcc_so.1
come from GCC 4.8's directory).

And if instead of calling `gcc48' (or `gfortran48') I create a CMakeLists.txt
and get CMake to generate a Makefile that will call the compiler, the results
are exactly the same, regardless of whether I pass
-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=YES to CMake or not.

And then if I want to use the ports tree infrastructure to call CMake for me, I
also get the same results. I'm attaching a .shar file with a test port called
"bug208120" that does exactly this (the source is based on code sent to me by
email by Ade and Diane). You can build it like a regular port, install it and
the "bug208120" binary will work just fine. It is also possible to just build
the code on your own and bypass the ports tree bits with `cd files && mkdir
build && cd build && FFLAGS=-Wl,-rpath=/usr/local/lib/gcc48 cmake .. && make
VERBOSE=1'.

> This sample network fails to compile, with gnuradio-companion failing: ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found
I tried looking for "gfortran48" invocations in
http://beefy4.nyi.freebsd.org/bulk/latest-per-pkg/gnuradio/3.7.8/head-amd64-default.log,
and comms/gnuradio only appears to have a USE_GCC=yes entry for FreeBSD 9.x.
It's unclear to me what is linking against libgfortran.so and how. It might be
the case that some Python library used by GNU Radio is trying to dlopen()
libgfortran, or it's actually a port that comms/gnuradio depends on that is
doing something wrong.

> This problem also affects arm and armv6.
I'm interested in hearing more about this. My knowledge about ARM and the ports
tree is zero, so please assume you're talking to a 5-year-old :-) Do you have a
link to a build log for a port that is being built incorrectly (ie. without the
right RPATH even though it is being passed to the linker)? Where/how should I
start if I wanted to investigate this and do my own tests?

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the kde-freebsd mailing list