[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply at freebsd.org]

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

--- Comment #29 from Diane Bruce <db at FreeBSD.org> ---
(In reply to Yuri Victorovich from comment #28)

See my various notes on this subject.
https://people.freebsd.org/~db/libgcc.txt
https://people.freebsd.org/~db/libgcc_removal_proposal.log

Agreed. It's not just a cmake problem. However, it appears cmake is DTRT
although
I thought groot at kde.org managed to duplicate my original error. There may never
have been a problem and I got it wrong. No matter. It was never intended as a
fix for the entire problem anyway. We have to as you noted again after I noted
it months ago ;) we either need a replacement libgcc that works, or a working
libquadmath that references our libgcc or a static libcc.

The static libgcc was looked at (I'll have to check my emails on this) but a
conflict was found with libunwind. (Which you have noted is a problem)

What I now believe to be happening is the following scenario. A program such as
python is compiled. In python2.7 case, there is no reference to a libgcc at all
hence no libgcc is linked. It then loads a module that *does* reference libgcc,
however it is the "wrong" libgcc. e.g. ldd -a
/usr/local/lib/libwx_gtk2u_stc-3.0.so|grep gcc
 libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80931f000)
...
Then the python program loads another module *which was* compiled against
gfortran or even gcc. e.g. openblas or atlas

 ldd /usr/local/lib/libblas.so 
/usr/local/lib/libblas.so:
        libgfortran.so.3 => /usr/local/lib/gcc5/libgfortran.so.3 (0x801252000)
        libm.so.5 => /lib/libm.so.5 (0x801574000)
        libgcc_s.so.1 => /usr/local/lib/gcc5/libgcc_s.so.1 (0x80179f000)
        libquadmath.so.0 => /usr/local/lib/gcc5/libquadmath.so.0 (0x8019b5000)
        libc.so.7 => /lib/libc.so.7 (0x800823000)

and. boom. hilarity results.

One possible solution that would work in the interim for many ports is a non
gfortran version of libblas. This is the "stick head in sand" approach since
whether we like it or not, fortran is *still* something we must support
properly.

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