On Thu, Jan 23, 2014 at 9:56 PM, John Marino <freebsd.cont...@marino.st>wrote:
> On 1/23/2014 20:53, Bernhard Fröhlich wrote: > > Am 23.01.2014 20:04 schrieb "Yuri" <y...@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.nose...@gmail.com> _______________________________________________ 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"