Re: USE_GCC doesn't set rpath
On Thu, 23 Jan 2014, Andrew W. Nosenko wrote: 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. Yes! And in a world hopefully not too far away at one point we'll just have a gcc-runtime port that comes from the _newest_ stable version of GCC in the ports tree and is used by all other versions. (In my day job, we have been doing this for years. Once we have several binary packages from one port, that ought to be relatively straightforward.) Gerald ___ 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
Re: USE_GCC doesn't set rpath
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 ___ 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
Re: USE_GCC doesn't set rpath
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. ___ 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
Re: USE_GCC doesn't set rpath
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++ ? John ___ 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
Re: USE_GCC doesn't set rpath
Am 23.01.2014 20:53, schrieb Bernhard Fröhlich: 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. 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. ___ 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
Re: USE_GCC doesn't set rpath
On 01/23/2014 11:56, John Marino wrote: 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++ ? It's not necessarily just C++. Python ports bound to C++ libraries with USE_GCC would create even more grave problem. It will be needed to create a special version of python with this rpath in it. And if there is a mix of different versions of gcc in various dependencies it would be just impossible to run such program due to conflicts. Yuri ___ 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
Re: USE_GCC doesn't set rpath
Am 23.01.2014 21:00 schrieb Matthias Andree matthias.and...@gmx.de: Am 23.01.2014 20:53, schrieb Bernhard Fröhlich: 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. 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 ___ 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
Re: USE_GCC doesn't set rpath
Am 23.01.2014 21:41, schrieb Bernhard Fröhlich: Am 23.01.2014 21:00 schrieb Matthias Andree matthias.and...@gmx.de mailto:matthias.and...@gmx.de: 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 I understand that, but I still expect the link to fail when the ABI is compatible. If not, some part of the system has a bad design, and requires fixing. One of the fixes we do not have, but that we need, is making linking libraries of incompatible ABIs fail at link-time, rather than at run-time. Rationale: If you can't get it built and installed, it obviously won't fail at runtime. I'd say the options are just two: 1. the canonical lang/gcc version (the one without version suffixes) and 2. the base system compiler (which won't give you OpenMP, for instance, on 10.0 - it uses a clang version that isn't OpenMP-enabled). Anything else is going to blow up. And to be really precise, it's down to the ABI and default libraries rather than the compiler. (Only it's so much easier to get clang to link with libstdc++ than getting GCC to link with libc++.) ___ 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
Re: USE_GCC doesn't set rpath
On Thu, Jan 23, 2014 at 9:56 PM, John Marino freebsd.cont...@marino.stwrote: 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
