USE_GCC doesn't set rpath

[Matthias Andree]

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.

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.

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.

> 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.