As documented on the LLVM site [1], the BUILD_SHARED_LIBS option is only recommended for LLVM developers to use. Normal users should use default static libs or use LLVM_BUILD_LLVM_DYLIB option that creates libLLVM.so library. For possible issues caused by this option see [2] (though it concerns Fedora). I might have stumbled upon a similar issue while trying to use RADV vulkan driver built from mesa, though I cannot reproduce it right now. [1] http://llvm.org/docs/CMake.html [2] https://lists.freedesktop.org/archives/mesa-dev/2016-February/107242.html
Static libraries are strongly discouraged in Gentoo because of security implications, and practically unusable on systems without lots of RAM (at least with GNU binutils). Single dylib might work but comes with the lot of static libraries. Back in the day when the decision was made, it was barely supported by different applications and usually involved a lot of hackery like guessing its name. It's a little better now but many apps still would use static libraries if static+dylib model was selected. Shared libraries work, and offer good split of functionality. I'm actively supporting them upstream, and so far I haven't met with any resistance from applying any fixes related to that. In fact, we only recently readded SONAMEs for this build variant. So the claim for it being 'unsupported' is wrong. As far as I can see, the potential issue at [2] clearly indicates a linker problem. However, I don't see that as being a reason to switch to an inferior solution. At least not until someone in Gentoo actually hits that.
I'm running into various errors from LLVM and all my google-fu is point towards LLVM being built with BUILD_SHARED_LIBS being on. (ex. handbrake, imagemagick. Although, I don't think either are directly depending on LLVM ...)
(In reply to Michael Cook from comment #2) > I'm running into various errors from LLVM and all my google-fu is point > towards LLVM being built with BUILD_SHARED_LIBS being on. (ex. handbrake, > imagemagick. Although, I don't think either are directly depending on LLVM > ...) I'm sorry but my crystal ball is currently offline. I can't help you if you don't tell us what the errors are and just jump to some random conclusions which -- as it already occurred to you -- make no sense.
(In reply to Michał Górny from comment #3) > (In reply to Michael Cook from comment #2) > > I'm running into various errors from LLVM and all my google-fu is point > > towards LLVM being built with BUILD_SHARED_LIBS being on. (ex. handbrake, > > imagemagick. Although, I don't think either are directly depending on LLVM > > ...) > > I'm sorry but my crystal ball is currently offline. I can't help you if you > don't tell us what the errors are and just jump to some random conclusions > which -- as it already occurred to you -- make no sense. I'm sorry, I'm not entirely sure where to start debugging this issue, which is why I went to google. The exact error I am getting (and if the original reporter is the same person having trouble on reddit, it's the same exact error) is : CommandLine Error: Option 'asan-instrument-assembly' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options I'm running HandBrakeCLI --loose-anamorphic --vfr -9 -5 -q 19.25 -E copy -e x264 -x -a -s -t 2 -o The.Venture.Bros.S05E01.mkv -i <folder to dvdbackup -M> Directly opening the DVD with the handbrake GUI also terminates eventually. Tried with 0.10.5-r2 and a fixed live ebuild. Same error. imagemagick I run convert -resize 500x500 foo.png new.png (haven't come across an image that hasn't failed yet ....) and get LLVM ERROR: Cannot select: 0x1bb6c40: i32,ch = AtomicLoadAdd<Volatile LDST4[%add.ptr1(addrspace=1)]> 0x22a8880, 0x198de70, Constant:i32<1> <bunch of LLVM errors> In function: Histogram Neither of these projects directly reference LLVM or clang, obviously something eventually does.
Running into this issue with kodi now too. Since https://github.com/xbmc/xbmc/commit/53b30b8a9dbb89573171c5827fbceb92ea255221 kodi will output a ": CommandLine Error: Option 'asan-instrument-assembly' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options" and eventually gets a SIGABRT. If I revert the changes in CWinSystemX11GLContext::GetVisual() from that commit I don't get any error messages and no SIGABRT. Upstream LLVM says BUILD_SHARED_LIBS is unsupported. Not sure why this is invalid when it keeps introducing issues.
Created attachment 496308 [details] kodi shared libraries from gdb's info sharedlibrary
