- libdispatch-dev - lists.macosforge.org

error: unknown attribute '_downgrade_exhaustivity_check'
by Ali Yousefi Sabzevar 05 Sep '17

05 Sep '17

Hi, TL;DR; /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Time.swift:127:3: error: unknown attribute '_downgrade_exhaustivity_check' @_downgrade_exhaustivity_check ^ /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/IO.swift:71:21: error: invalid redeclaration of 'init(type:path:oflag:mode:queue:cleanupHandler:)' public convenience init?( ^ I'm going to build Swift rpm package from source on Fedora 26. This error occurs with 3.1 and 3.1.1 releases of swift and its dependencies including swift-llbuild, swift-cmark, swift-lldb, etc. I used this script ( https://github.com/corinnekrych/swift-rpm/blob/master/rpm-from-source.sh) and changed it a bit in order to work in Fedora 26 (it apparently worked on previous versions of Fedora). The latest error(s) I faced is(are): """ /home/ali/rpmbuild/BUILD/build/buildbot_linux/swift-linux-x86_64/bin/swiftc -whole-module-optimization -emit-library -c /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Block.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Data.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Dispatch.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/IO.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Private.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Queue.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Source.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Time.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Wrapper.swift \ -Xcc -fmodule-map-file=/home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/dispatch/module.modulemap -I/home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch -Xcc -fblocks -O -module-name Dispatch -module-link-name dispatch \ -o /home/ali/rpmbuild/BUILD/build/buildbot_linux/libdispatch-linux-x86_64/src/swift/swift_overlay.o -emit-module-path /home/ali/rpmbuild/BUILD/build/buildbot_linux/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Time.swift:127:3: error: unknown attribute '_downgrade_exhaustivity_check' @_downgrade_exhaustivity_check ^ /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/IO.swift:71:21: error: invalid redeclaration of 'init(type:path:oflag:mode:queue:cleanupHandler:)' public convenience init?( ^ /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/IO.swift:59:21: note: 'init(type:path:oflag:mode:queue:cleanupHandler:)' previously declared here public convenience init( ^ make[2]: *** [Makefile:1004: /home/ali/rpmbuild/BUILD/build/buildbot_linux/libdispatch-linux-x86_64/src/swift/swift_overlay.o] Error 1 make[2]: Leaving directory '/home/ali/rpmbuild/BUILD/build/buildbot_linux/libdispatch-linux-x86_64/src' make[1]: *** [Makefile:545: all] Error 2 make[1]: Leaving directory '/home/ali/rpmbuild/BUILD/build/buildbot_linux/libdispatch-linux-x86_64/src' make: *** [Makefile:453: all-recursive] Error 1 ./utils/build-script: fatal error: command terminated with a non-zero exit status 2, aborting ./utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting error: Bad exit status from /var/tmp/rpm-tmp.VPka9M (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.VPka9M (%build) """ Please let me know if you need something else.

1 0

error: unknown attribute '_downgrade_exhaustivity_check'
by Ali Yousefi Sabzevar 04 Sep '17

04 Sep '17

TL;DR; /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Time.swift:127:3: error: unknown attribute '_downgrade_exhaustivity_check' @_downgrade_exhaustivity_check ^ /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/IO.swift:71:21: error: invalid redeclaration of 'init(type:path:oflag:mode:queue:cleanupHandler:)' public convenience init?( ^ I'm going to build Swift rpm package from source on Fedora 26. This error occurs with 3.1 and 3.1.1 releases of swift and its dependencies including swift-llbuild, swift-cmark, swift-lldb, etc. I used this script ( https://github.com/corinnekrych/swift-rpm/blob/master/rpm-from-source.sh) and changed it a bit in order to work in Fedora 26 (it apparently worked on previous versions of Fedora). The latest error(s) I faced is(are): """ /home/ali/rpmbuild/BUILD/build/buildbot_linux/swift-linux-x86_64/bin/swiftc -whole-module-optimization -emit-library -c /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Block.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Data.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Dispatch.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/IO.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Private.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Queue.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Source.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Time.swift /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Wrapper.swift \ -Xcc -fmodule-map-file=/home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/dispatch/module.modulemap -I/home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch -Xcc -fblocks -O -module-name Dispatch -module-link-name dispatch \ -o /home/ali/rpmbuild/BUILD/build/buildbot_linux/libdispatch-linux-x86_64/src/swift/swift_overlay.o -emit-module-path /home/ali/rpmbuild/BUILD/build/buildbot_linux/libdispatch-linux-x86_64/src/swift/Dispatch.swiftmodule /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/Time.swift:127:3: error: unknown attribute '_downgrade_exhaustivity_check' @_downgrade_exhaustivity_check ^ /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/IO.swift:71:21: error: invalid redeclaration of 'init(type:path:oflag:mode:queue:cleanupHandler:)' public convenience init?( ^ /home/ali/rpmbuild/BUILD/swift-corelibs-libdispatch/src/swift/IO.swift:59:21: note: 'init(type:path:oflag:mode:queue:cleanupHandler:)' previously declared here public convenience init( ^ make[2]: *** [Makefile:1004: /home/ali/rpmbuild/BUILD/build/buildbot_linux/libdispatch-linux-x86_64/src/swift/swift_overlay.o] Error 1 make[2]: Leaving directory '/home/ali/rpmbuild/BUILD/build/buildbot_linux/libdispatch-linux-x86_64/src' make[1]: *** [Makefile:545: all] Error 2 make[1]: Leaving directory '/home/ali/rpmbuild/BUILD/build/buildbot_linux/libdispatch-linux-x86_64/src' make: *** [Makefile:453: all-recursive] Error 1 ./utils/build-script: fatal error: command terminated with a non-zero exit status 2, aborting ./utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting error: Bad exit status from /var/tmp/rpm-tmp.VPka9M (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.VPka9M (%build) """ Please let me know if you need something else. Ali

1 0

DISPATCH_SOURCE_TYPE_READ fails with serial port file descriptors
by Hans Kröner 20 Oct '16

20 Oct '16

Hi everyone, For a while now (since 10.8) I've been using dispatch_sources to read from serial ports. Up until 10.11.6 everything has been fine, but on 10.12.0 the source's event handler is not always being called when data is available for reading. I see it called a few times, but it often "stops" being called after a second or two - especially if new data has arrived on the serial port. If the source's file descriptor happens to be a regular file, and not a serial port, everything continues to behave as expected. Has anybody else experienced something similar to this? I can provide a short code sample that exemplifies the issue, but you'll need a serial device sending data to the serial port in order to test it. Thanks in advance! /Hans

2 1

Quality of service changes to the default priority queue
by Thomas Clement 16 Mar '16

16 Mar '16

Starting with 10.10, it seems the default priority queue has changed meaning from a middleground priority queue into a special queue with no specific priority attached. One consequence is that a default priority queue will now inherit the quality of service from the queue that submits the block (see DISPATCH_BLOCK_INHERIT_QOS_CLASS). dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{ // Code A dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ // Code B }); }); So code like this used to execute Code A in background priority and Code B in default priority. Now it executes both in background priority. So it seems this change breaks backward compatibility with existing code intent. Is there any suggestion as how to deal with this and potentially revert to the old behavior (if at all possible), considering the code must deploy back to 10.9. Regards, Thomas

1 0

Fwd: Race in dispatch_semaphore_wait(DISPATCH_TIME_NOW)
by Dmitri Shubin 22 May '14

22 May '14

(forwarding to list) Hi Dave, On Wed, May 21, 2014 at 8:54 PM, Dave Zarzycki <zarzycki(a)apple.com> wrote: > > This is almost surely a bug in the port to these platforms. Apple’s > operating system uses Mach to implement this feature, but Mach is not > available on Linux and Solaris. > AFAIU libdispatch on OS X uses Mach semaphores instead of POSIX ones used on Linux/Solaris. But the issue is irrelevant to OS semaphore implementation. Actually I tried to reproduce it on OS X using (named) POSIX semaphores but failed. I.e. the same (racy) code that hangs on Linux/Solaris doesn't hang on OS X. I even tried simple semaphore implementation using mutex+condition variable but again no luck on OS X. My guess is that this is related to differences in thread scheduler implementations on these OS'es.

1 0

Race in dispatch_semaphore_wait(DISPATCH_TIME_NOW)
by Dmitri Shubin 21 May '14

21 May '14

Hi! In our application we assume that dispatch_semaphore_wait(sema, DISPATCH_TIME_NOW) will never block, but recently we found it waiting on OS semaphore. Checking source of libdispatch (we used version 215, but the latest available 339.90.1 seems similar) we found the following scenario that could lead to blocking. Thread1: dispatch_semaphore_wait(sema, DISPATCH_TIME_NOW); Thread2: dispatch_semaphore_signal(sema); dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER); Initial state: dsema_value = 0, internal OS semaphore count = 0 1. Thread 1 enters dispatch_semaphore_wait() and decrements dsema_value -> -1, it's < 0, so going slow path. 2. Thread 2 signals semaphore, dsema_value incremented from -1 to 0, also going slow path and signals OS semaphore, incrementing its count from 0 to 1. 3. Thread 1 enters DISPATCH_TIME_NOW case in switch in dispatch_semaphore_wait_slow(), but since dsema_value == 0 falls through to DISPATCH_TIME_FOREVER case. 4. Thread 2 enters dispatch_semaphore_wait, decrements dsema_value from 0 to -1, goes slow path, waits on OS semaphore, decrements its count back to 0 and exits dispatch_semaphore_wait() 5. Thread 1 waits forever on OS semaphore. Interesting that simple test that we wrote to expose that race can easily show it on Linux (e.g. need 1-5 runs). More runs are needed to see it on Solaris (~5-10 runs). But we failed to make it hung on OS X (10.9.3) Is there some changes that are not included in open source libdispatch? Please check if our analysis is correct. Thanks!

2 1

libdispatch threads stack size
by Thomas Clement 07 Mar '14

07 Mar '14

Hello folks, We are using a library (out of our control) which is crashing our program apparently because it consumes all available stack space. We are not in control of the underlying threads since they are created by the libdispatch. Anything we can do here or are we back to managing pthreads? Regards, Thomas

4 3

Fwd: [Bug libc/11157] __block is a reserved word with clang -fblocks
by Mark Heily 26 Nov '13

26 Nov '13

Good news: it appears that the glibc maintainers have accepted a patch to allow the use of __block as a Clang keyword. This should make it easier to build libdispatch and programs that use the Blocks compiler extension. ---------- Forwarded message ---------- From: carlos at redhat dot com <sourceware-bugzilla(a)sourceware.org> Date: Thu, Nov 21, 2013 at 5:06 PM Subject: [Bug libc/11157] __block is a reserved word with clang -fblocks To: mark(a)heily.com https://sourceware.org/bugzilla/show_bug.cgi?id=11157 Carlos O'Donell <carlos at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carlos at redhat dot com Resolution|WONTFIX |FIXED --- Comment #10 from Carlos O'Donell <carlos at redhat dot com> --- Fixed. commit 84ae135d3282dc362bed0a5c9a575319ef336884 Author: Meador Inge <meadori(a)codesourcery.com> Date: Thu Nov 21 16:57:37 2013 -0500 Use __glibc_block in public headers. As detailed in PR11157, the use of '__block' is known to interfere with keywords in some environments, such as the Clang -fblocks extension. Recently a similar issue was raised concerning the use of '__unused' and a '__glibc' prefix was proposed to create a glibc implementation namespace for these sorts of issues [1]. This patches takes that approach. [1] https://sourceware.org/ml/libc-alpha/2012-02/msg00047.html [2] http://lists.debian.org/debian-glibc/2013/11/msg00020.html -- You are receiving this mail because: You are on the CC list for the bug.

2 1

Replacement for dispatch_get_current_queue
by Adam Ernst 20 Apr '13

20 Apr '13

The design of dispatch_get_current_queue is clearly problematic, as its docs indicate. I've heard rumors the function will be deprecated and removed soon. We currently use it for queue affinity asserts (for which it serves ably). Is there any plan on what it might be replaced with for this purpose? Adam

4 3

Build and compile with libdispatch and -fobjc-arc on Linux
by Frank Rehwinkel 15 Mar '13

15 Mar '13

Am looking for confirmation of what should be working and what build flags to use to make this work. On a Debian-based Linux system, Ubuntu 64-bit 12.04 or 12.10, using trunk from libobjc2, for Objective-C code to use Clang's -fobjc-arc that also wants to link with the libdispatch library, what is the recommended set of flags for building libdispatch and for building the code itself? What I've tried so far hasn't worked but rather than clutter this first post with all my attempts and the compiler error and later the execution failure, I thought it worth checking that I am starting with the proper base. I have found nothing online about using libdispatch with automatic reference counting on Linux. Both are such powerful tools I was surprised not to find this all spelled out already so I wonder if it just works for others or if no one else has tried. For the build of libdispatch, I followed this recipe: cd libdispatch-src sh autogen.sh ./configure CFLAGS="-I/usr/include/kqueue" LDFLAGS="-lkqueue -lpthread_workqueue -pthread -lm" make sudo -E make install sudo ldconfig And to build the Objective-C source with GNUstep's libobjc2 runtime library, I used these flags. clang testfile.m `gnustep-config --objc-flags` `gnustep-config --objc-libs` -fobjc-runtime=gnustep-1.7 -fblocks -lobjc -ldispatch -lgnustep-base I'm using the svn trunk for libobjc2 as that has a recent bug fix for blocks and ARC. I pulled the libdispatch src from git:// github.com/nickhutchinson/libdispatch.git. If noone has any suggestion for a different build approach, I will attach the compile error I ran into and then the runtime error that is left to figure out. Thank you, -Frank

1 0