Date: Thu, 23 Jan 2014 21:41:07 +0100 From: =?ISO-8859-1?Q?Bernhard_Fr=F6hlich?= <decke@bluelife.at> To: Matthias Andree <matthias.andree@gmx.de> Cc: ports <freebsd-ports@freebsd.org> Subject: Re: USE_GCC doesn't set rpath Message-ID: <CAE-m3X1Bhc02yKh%2BXxCvYrfF0LP0njUyLA2224%2BTENGeqe9boA@mail.gmail.com> In-Reply-To: <52E174CC.1020801@gmx.de> References: <52DEE7EE.6010909@rawbw.com> <52DF0346.6000108@ShaneWare.Biz> <52E167BF.8050103@rawbw.com> <CAE-m3X0cMxJ_mpPZ_AoDb17G9Dg4F_Sj45KsZi-hYnd9mguhLw@mail.gmail.com> <52E174CC.1020801@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 23.01.2014 21:00 schrieb "Matthias Andree" <matthias.andree@gmx.de>: > > Am 23.01.2014 20:53, schrieb Bernhard Fr=F6hlich: > > Am 23.01.2014 20:04 schrieb "Yuri" <yuri@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 load= s > >>> 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 mor= e > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAE-m3X1Bhc02yKh%2BXxCvYrfF0LP0njUyLA2224%2BTENGeqe9boA>