USE_GCC doesn't set rpath

[Bernhard Fröhlich]

Am 23.01.2014 21:00 schrieb "Matthias Andree" <matthias.andree at gmx.de>:
>
> Am 23.01.2014 20:53, schrieb Bernhard Fröhlich:
> > 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.
>
> No reason to use offensive language.

The reason is my frustration on that topic.

> We can technically provide/use different ports compilers, the only thing
> is that we need to make sure to separate ports by their ABI.  I. e.
> clang-built C++ ports require clang-built C++ requisites.  Meaning that
> you may need to install the same library twice, once with GCC47 ABI,
> once with clang ABI - and of course the rpath needs to be set accordingly.

>From what I know about how we build packaged and how the portstree works I
think it's nearly impossible to do that. The bloat and resources we waste
with that sounds even worse.

> Possibly we also need to provide only static versions of
> compiler-dependent libs (such as libcompiler-rt for clang and libgcc*
> for GCC) to overcome the particular problem Bernhard is describing.
>
> Again, this mostly affects C++ ports, and to a lesser extent Objective-C
> ports.

Yes that's true but since a lot of desktop stuff is c++ based nowadays and
uses boost this affects quite a few people.

> > 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.
>
> If the ABIs are not compatible, then linking should not work - for
> instance, if I compile rawtherapee with GCC, it will not link against
> requisites built with clang.

No the problems I mean are at runtime. An example is if you have a gcc
programm that loads other components like Qt stuff that was compiled with
clang them there are some subtile differences that will cause crashes. This
might also be some strange bug in our old gcc toolchain but so far nobody
had a clue what is going wrong there.

http://lists.freebsd.org/pipermail/freebsd-emulation/2013-September/010769.html