[SR-415] blocks support in external c libraries disabled

[swift-ci]

Previous ID	SR-415
Radar	None
Original Reporter	dunkelstern (JIRA User)
Type	Bug
Status	Resolved
Resolution	Duplicate

Environment

Snapshot from 2015-12-22 on Ubuntu 15.10

Additional Detail from JIRA

Votes	0
Component/s	Compiler, Package Manager
Labels	Bug
Assignee	None
Priority	Medium

md5: 8b498b23f358b9220a306299718d7edd

duplicates:

• SR-397 Linux - module using <dispatch/dispatch.h> does not compile cleanly with "swift build"

Issue Description:

I wanted to do some code in C because of missing support in Swift (try to use a socket interface, that casting is horrible) so I did the "complex" part in C and just wanted to call back into swift with the data.

If you use a C-Function pointer as callback interface you'll get:
"error: a C function pointer cannot be formed from a closure that captures context"

that sounds reasonable so i tried to use a clang block callback but then i get:
"error: blocks support disabled - compile with -fblocks or pick a deployment target that supports them"

I know for compiling my C test program that uses the interface I have to link against "BlocksRuntime" and compile with "-fBlocks" but how do I set the compile parameter with "swift build"?

If you want to see what I want to do look here: https://github.com/dunkelstern/libUnchainedSocket

(current github checkin with tag 0.0.1 has the c function pointer interface, see branch "blocks" for the blocks version, you'll need "libblocksruntime-dev")

[swift-ci]

Comment by Johannes Schriewer (JIRA)

If i add the line
requires blocks

to the module map file it complains with:
<unknown>:0: error: module 'UnchainedSocket' requires feature 'blocks'

So i assume blocks are not supported under Linux?
On OS X it works flawlessly...

[drewcrawford]

I've PRed a workaround for this issue, #107. If that PR is merged, we can say

otherCompilerOptions: ["-Xcc", "-fblocks"] 

to work around this bug.

[swift-ci]

Comment by Johannes Schriewer (JIRA)

Dupes SR-397: Same issue, different library trying to link against

[mxcl]

This isn't strictly a dupe. SR-397 is a module map issue which this should be a C-target issue when that support has been added. See Daniel's proposal on the mailing list.