USE_GCC doesn't set rpath

[Andrew W. Nosenko]

On Thu, Jan 23, 2014 at 9:56 PM, John Marino <freebsd.contact at marino.st>wrote:

> On 1/23/2014 20:53, Bernhard Fröhlich wrote:
> > Am 23.01.2014 20:04 schrieb "Yuri" <yuri at rawbw.com>:
> >>
> >> On 01/21/2014 15:31, Shane Ambler wrote:
> >>>
> >>> I think you will find that qbittorrent will need to be built with the
> >>> same gcc version as libtorrent-rasterbar.
> >>>
> >>> I believe qbittorrent is loading /usr/lib/libstdc++.so.6 then it loads
> >>> libtorrent-rasterbar.so.7 which tries to load libstdc++ and it is given
> >>> the already open copy which doesn't have GLIBCXX_3.4.15 that it needs
> to
> >>> run.
> >>
> >>
> >> Yes, you are right, thst's what is happening.
> >> So if any dependency has USE_GCC set, all dependent packages should also
> > have USE_GCC set. Can ports build infrastructure automatically set
> USE_GCC
> > for dependent ports? Because doing this by hand in each port is tedious
> and
> > error prone.
> >>
> >> Yuri
> >
> > No it can't right now and this is why we need a ports compiler. Right now
> > we are hiding this problems by the fact that we are able to build 95%
> > percent of the tree with clang and everyone is happy. We add dozens of
> > patches to compile with clang or add this rpath workarounds to even more
> > ports just because nobody wants to acknowledge that this is shit and
> won't
> > work properly unless really everything is build with one compiler.
> >
> > The rpath stuff is only a workaround that works in a few cases but it
> > doesn't work in all cases. You will still see very hard to diagnose
> runtime
> > crashes.
>
> While I basically agree with this sentiment, is not it just ports that
> use C++ that are affected?  Could not this be narrowed down to "We need
> a single compiler for ports that use C++" ?
>

No.  Everything that uses language- or feature-support library are
affected.  I'm, for example, unable to use OpenMP higher than 2.5 even if
compiler is gcc-4.8, which is openmp-3.x capable).

But, from my point of view, the problem is not a compiler nor rpath.  rpath
is unneeded indeed, and library indeed may be only one (under /lib).  The
real problem is that this is ancient library, not the most recent one.
 They are especially designed to be backward compatible and have the same
so-number for a reason.

-- 
Andrew W. Nosenko <andrew.w.nosenko at gmail.com>