First off thanks for the help.
No doubt I'm doing something wrong. I wish I could help debug my own
problem but I don't really get what @_silgen_name does. That seems like
black magic to me.
That compiled though now it won't link. I've put the code up as a
Gist here[1].
$ swift build Linking Executable: .build/debug/CastableLive
/home/ryan/Source/castable-
live/.build/debug/CastableLive.o/main.swift.o: In function
`_TFC12CastableLive6DVBDVRcfT7adapterSi6numberSi_GSqS0__':
/home/ryan/Source/castable-
live/main.swift:40: undefined reference to `ioctl' /usr/bin/ld:
/home/ryan/Source/castable-
live/.build/debug/CastableLive: hidden symbol `ioctl' isn't defined
/usr/bin/ld: final link failed: Bad value clang-3.7: error: linker
command failed with exit code 1 (use -v to see invocation) <unknown>:0:
error: link command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: build had 1 command failures error: exit(1):
["/usr/bin/swift-build-
tool", "-f", "/home/ryan/Source/castable-
live/.build/debug/CastableLive.o/llbuild.yaml"]
On Tue, Jan 5, 2016, at 04:57 PM, Kate Stone wrote:
>> On Jan 5, 2016, at 12:32 PM, Ryan Lovelett via swift-dev <swift-
>> d...@swift.org> wrote:
>>
>> Just to be clear though the intent of my question was not to quibble
>> with compiler error messages. My real question is how are we meant to
>> do systems programming with Swift on Linux if we cannot call ioctl?
> In the absence of an automatic mechanism for importing the definition
> of variadic functions you can still define your own prototypes and
> bind them to the system implementation. For example, this
> declaration:
>
> @_silgen_name("ioctl") func ioctl(fildes: CInt, request: UInt64,
> result: UnsafePointer<Int>) -> Int
>
> … gives you a non-variadic interface to ioctl that you can use for
> invocations that conform to this specific convention. You can define
> as many overloads as you wish, and so long as you’re cautious about
> which one you’re using for a given request you should be able to make
> progress.
>
> The same basic strategy can be applied to any variadic functional
> interfaces. Ideally you’d want to hide this implementation detail
> behind a more Swift-friendly API where the request type is implied to
> create a more type-safe interface.
>
> Kate stonek8st...@apple.com Xcode Low Level Tools
>
Links:
1. https://gist.github.com/anonymous/4861aba2280251fe57c6
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
