* Press Ctrl-C to Stop * * dev-libs/libdispatch-5.3.3-r1:0::gentoo * /usr/lib64/libBlocksRuntime.so * * Package 'sys-libs/blocksruntime-0_pre20171027-r1' NOT merged due to ------------------------------------------------------------------- This is an stable amd64 chroot image at a tinderbox (==build bot) name: 17.1_systemd-j4_stable-20221008-230003 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-11.3.0 * clang/llvm (if any): clang version 14.0.6 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/14/bin /usr/lib/llvm/14 14.0.6 Python 3.10.6 Available Ruby profiles: [1] ruby27 (with Rubygems) * Available Rust versions: [1] rust-bin-1.64.0 * The following VMs are available for generation-2: 1) IcedTea JDK 3.16.0 [icedtea-bin-8] 2) Eclipse Temurin JDK 11.0.15_p10 [openjdk-bin-11] *) Eclipse Temurin JDK 17.0.3_p7 [openjdk-bin-17] 4) Eclipse Temurin JDK 8.332_p09 [openjdk-bin-8] Available Java Virtual Machines: [1] icedtea-bin-8 [2] openjdk-bin-8 [3] openjdk-bin-11 [4] openjdk-bin-17 system-vm php cli (if any): GNU Make 4.3 HEAD of ::gentoo commit e8ec1034d2195bb7d5c82b9d7fcb5977b785a279 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Wed Oct 12 20:34:01 2022 +0000 2022-10-12 20:34:01 UTC emerge -qpvO sys-libs/blocksruntime [ebuild N ] sys-libs/blocksruntime-0_pre20171027-r1 USE="-static-libs"
Created attachment 823757 [details] emerge-info.txt
Created attachment 823759 [details] emerge-history.txt.bz2
Created attachment 823761 [details] etc.portage.tar.bz2
Created attachment 823763 [details] logs.tar.bz2
Created attachment 823765 [details] sys-libs:blocksruntime-0_pre20171027-r1:20221012-213728.log
libdispatch bundles blocksruntime - compare ${S}/src/BlocksRuntime in the former with ${S}/BlocksRuntime in the latter.
With this bug being now assigned to me, can you tell me what you expect me to do with it, exactly?
(In reply to Piotr Karbowski from comment #7) > With this bug being now assigned to me, can you tell me what you expect me > to do with it, exactly? Unbundle blocksruntime (stop installing its libraries and depend on the system copy).
Very well, will look into it somewhere over this weekend.
Are you entirely sure the bundled library is sys-libs/blocksruntime? I spent some time on this bug and it does not looks to me like this is the case, the same name but not the same library, t he interfaces does not match.
Upon further investigation seems like I can get it working but first we'd need to modify the blocksruntime package to actually install into normal /usr/include rather than subdir, since this is where libdispatch and deadbeef both would expect it to be. Any help appreciated.
After all, I have no luck linking libdispatch with blockruntime even via libobjc2. Apple also refused to allow it in https://github.com/apple/swift-corelibs-libdispatch/pull/534app-forensics/honggfuzz I did a quick look at how others do it, in Ubuntu they have entirely different old version of libdispatch around, archlinux however uses libdispatch as libblocksruntime provider. In tree only net-misc/asterisk and app-forensics/honggfuzz depends on sys-libs/blocksruntime, perhaps we could go with libdispatch as the Blocks provider, like in Archlinux, but then it would continue to conflict with libobjc2. I ran out of ideas.
Unfortunate! Okay, I'd either statically link libdispatch to its BlocksRuntime (given clearly nothing is supposed to use it on the system anyway) or install it to a subdir like /usr/lib64/libdispatch and add that to RPATH.
I did looked into statically linking it but I do not think this is the way to go because the actual customer of both libdispatch and libblocksruntime is media-sound/deadbeef that uses both Blocks.h and links to both libraries. To prevent it from conflicting with gnustep-base/libobjc2 and sys-libs/blocksruntime both the libraries and the header would need to go into subdirectories but neither provides .pc to integrate with it easy. Which means that packages using libdispatch and/or libblocksruntime would require patching to include the header from subdirectory, which is fairly easy, but also something to embed RPATH in executables and libraries it creates so it loads the right libblocksruntime.so and does not the other one, we cannot rely then on default LD_LIBRARY_PATH. Currently media-sound/deadbeef uses Blocks.h and links to libblocksruntime.so and libdispatch.so, but in tree I also see net-im/telegram-desktop depending on libdispatch, though I do not see in code any place it uses it. I wonder if its really make sense to do those instead of using Apple's BlocksRuntime as the BlocksRuntime much like ArchLinux does. I however have zero understanding of the situation with multiple Blocks providers so I'd appreciate some direction here.
Any opinions what we do with this one? The title of bug claims the libdispatch bundles sys-libs/blocksruntime which actually is not the case as the headers and interfaces are slightly different, I just diffed around files like Blocks.h and Blocks_private.h to check on it, and we concluded that those are in fact different things. They clearly conflict with each other but does not seems to be interchangeable, there's no clear solution here that does not pulls in issues, like we could install both on side and then modify all of the clients of libdispatch and Blocks to pull this version if this is what those are supposed to use, like deadbeef is one of them. I am leaning toward closing it as either CANTFIX or INVALID, opinions?
You obviously can't do either of those. The first thing you can do is add a blocker. As for moving the library: it may well be enough to "just" move it and adjust its pkg-config file.
Neither libdispatch nor the Swift's BlocksRuntime provides .pc, if it had I would do it there long time ago. Without .pc I would need to patch build system of every dependent package, tier 3 hackery. I will then go ahead and close this one as INVALID given the BlocksRuntime implementation that it bundles is not sys-libs/blocksruntime but Apple's own one and the blocker on sys-libs/blocksruntime was added on 2022-02-06 already with bump of version 5.5. I am still open though to get back to it if someone have idea how to handle it in another way.
wait, how did you add a blocker in Feb if this bug is way newer?
I suspect it was stable run. stable arch has non-blocked version. I will raise stablereq for current version.
To be clear, I changed INVALID -> CANTFIX because the library genuinely is bundled but they diverged upstream years ago (compare the headers and history of them). Also, I usually see INVALID as "the bug had no basis", but it did in that: 1. there's a blocker now (yay!) 2. there genuinely was something to investigate, it just turned out unbundling isn't feasible. CANTFIX is more clear that there's a genuine dilemma/issue here rather than a dodgy report from toralf.
(In reply to Sam James from comment #16) > You obviously can't do either of those. The first thing you can do is add a > blocker. > what I meant here was: you can't just close it as INVALID/CANTFIX by itself, I didn't realise there was a blocker, but as you mentioned later, the reason this bug happened is b/c of overdue stabilisation, so that would be the fix here (which you've filed now, thanks).
