On Thu, Aug 06 2020, Nam Nguyen <n...@berkeley.edu> wrote: > This diff backports a 10.0.1 fix for an llvm crash while compiling > net/libtorrent-rasterbar web_connection-base.cpp and > bt_peer_connection.cpp. > > I compiled an earlier version of jca@'s update to devel/llvm 10 with > debug symbols to get this backtrace: > https://namtsui.com/public/libtorrent-rasterbar-bt.txt > > - added -DCMAKE_BUILD_TYPE=Debug > - make DEBUG=-g CFLAGS=-g CXXFLAGS=-g clean configure > > The debug version of llvm was extremely slow at compiling > libtorrent-rasterbar, so I had to use a release build. > > I searched for EmitEndEHSpec and found an existing bug report from > 2019. Arvid Norberg responded to the thread and is upstream for > libtorrent-rasterbar. > > https://bugs.llvm.org/show_bug.cgi?id=43814 > https://github.com/llvm/llvm-project/commit/68cd4f72beae67a9bdbc11c85fd745dec8fc0999 > > I propose adding this inline diff for devel/llvm now.
Done, I have committed your diff + a few other tweaks yesterday. I have pointed this bug and your diff to the folks who handled the LLVM update in base. There have been discussions about moving to llvm-10.0.1. > I propose waiting until rsadowski@'s devel/boost 1.67 before unbreaking > libtorrent-rasterbar. I can look into updating libtorrent-rasterbar to > 1.2.8 until then. There is discussion regarding a mechanism for boost > python numbering. Is libtorrent-rasterbar currently broken for other reasons? If possible, I'd prefer if we could update/fix base-clang instead of moving libtorrent-rasterbar to ports-clang. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
