Development discussion of WireGuard
 help / color / mirror / Atom feed
* [wireguard-apple] [iOS] Running WireGuard on a simulator
@ 2021-09-02  0:57 Neutron
  2021-09-02  1:20 ` Jeffrey Walton
  2021-09-02  2:10 ` Jeffrey Walton
  0 siblings, 2 replies; 5+ messages in thread
From: Neutron @ 2021-09-02  0:57 UTC (permalink / raw)
  To: WireGuard mailing list; +Cc: Jason A. Donenfeld, roop

Hello,

I've tried running wireguard-apple on an iOS simulator and encountered some
trouble during the compilation of WireGuardKitGo. I did this on an Apple M1,
which I thought at first would be the culprit.

The Go version is "go1.16 darwin/arm64". The build process fails at
# runtime/cgo
Undefined symbols for architecture arm64:
  "_darwin_arm_init_mach_exception_handler", referenced from:
      _x_cgo_init in _x004.o
  "_darwin_arm_init_thread_exception_port", referenced from:
      _threadentry in _x004.o
      _x_cgo_init in _x004.o
ld: symbol(s) not found for architecture arm64

This issue was reported a few times in Go's issues section, e.g.,
https://github.com/golang/go/issues/45772#issuecomment-874616905

Further head banging lead me to the discovery that

xcodebuild -target WireGuardiOS -sdk iphoneos14.5

actually builds successfully. I looked through the Makefile and applied some
monkey see, monkey do. It turns out I could get it to link by adding
GOOS_iphonesimulator := ios.

For a moment I thought this was a definite win, but it turns out connecting to
one of the test tunnels doesn't do anything. I hit a dead end after finding this
answer on a forum thread.

https://developer.apple.com/forums/thread/651779?answerId=617050022#617050022

"If you’re talking about the iOS Simulator here, be aware that, because of the
way they interact with the networking stack, NetworkExtension providers only
work on real hardware."

I don't have an actual iPhone on hand at the moment, so I guess the question is,
is the project supposed to work only on real hardware? Was that flag left out
intentionally? If so, is there a way to get it to run properly on simulators?

I'm a neophyte when it comes to anything iOS related, so perhaps someone
with more experience can shed some light on the subject.

Neutron

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [wireguard-apple] [iOS] Running WireGuard on a simulator
  2021-09-02  0:57 [wireguard-apple] [iOS] Running WireGuard on a simulator Neutron
@ 2021-09-02  1:20 ` Jeffrey Walton
  2021-09-02  2:10 ` Jeffrey Walton
  1 sibling, 0 replies; 5+ messages in thread
From: Jeffrey Walton @ 2021-09-02  1:20 UTC (permalink / raw)
  To: WireGuard mailing list

On Wed, Sep 1, 2021 at 9:00 PM Neutron <dotneutron@protonmail.ch> wrote:
>
> I've tried running wireguard-apple on an iOS simulator and encountered some
> trouble during the compilation of WireGuardKitGo. I did this on an Apple M1,
> which I thought at first would be the culprit.
>
> The Go version is "go1.16 darwin/arm64". The build process fails at
> # runtime/cgo
> Undefined symbols for architecture arm64:
>   "_darwin_arm_init_mach_exception_handler", referenced from:
>       _x_cgo_init in _x004.o
>   "_darwin_arm_init_thread_exception_port", referenced from:
>       _threadentry in _x004.o
>       _x_cgo_init in _x004.o
> ld: symbol(s) not found for architecture arm64
>
> This issue was reported a few times in Go's issues section, e.g.,
> https://github.com/golang/go/issues/45772#issuecomment-874616905
>
> Further head banging lead me to the discovery that
>
> xcodebuild -target WireGuardiOS -sdk iphoneos14.5

Yeah, whenever you start seeing problems with missing symbols related
to exception handlers, you should look at the target SDK. I see it a
lot when trying to cross compile for Apple WatchOS and AppleTV when
using the wrong SDK.

Besides -sdk, other ones to look for are -miphoneos-version-min,
-miphonesimulator-version-min, -mappletvos-version-min,
-mappletvsimulator-version-min, -mwatchos-version-min and
-mwatchsimulator-version-min. If you drop them too low, you will break
during link with the missing exception handlers.

I think what happens is, the headers mostly work with a lot of
different targets. But the exception handlers are specific to a
particular SDK, and you only have a limited range of them installed
(otherwise, you have to install older versions of Xcode and older
SDKs).

I don't know how Go affects things. I usually work with native C/C++/ObjC code.

> I don't have an actual iPhone on hand at the moment,
> so I guess the question is, is the project supposed to
> work only on real hardware? Was that flag left out
> intentionally? If so, is there a way to get it to run
> properly on simulators?

In the past, the network stack was crippled on the simulator. I don't
know if that's the case nowadays. I think Android is about the same.
It is hard to test some of this stuff on a simulator or emulator.

Jeff

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [wireguard-apple] [iOS] Running WireGuard on a simulator
  2021-09-02  0:57 [wireguard-apple] [iOS] Running WireGuard on a simulator Neutron
  2021-09-02  1:20 ` Jeffrey Walton
@ 2021-09-02  2:10 ` Jeffrey Walton
  2021-09-02  6:48   ` Neutron
  1 sibling, 1 reply; 5+ messages in thread
From: Jeffrey Walton @ 2021-09-02  2:10 UTC (permalink / raw)
  To: WireGuard mailing list

On Wed, Sep 1, 2021 at 9:00 PM Neutron <dotneutron@protonmail.ch> wrote:
> ...
>
> The Go version is "go1.16 darwin/arm64". The build process fails at
> # runtime/cgo
> Undefined symbols for architecture arm64:
>   "_darwin_arm_init_mach_exception_handler", referenced from:
>       _x_cgo_init in _x004.o
>   "_darwin_arm_init_thread_exception_port", referenced from:
>       _threadentry in _x004.o
>       _x_cgo_init in _x004.o
> ld: symbol(s) not found for architecture arm64
>
> This issue was reported a few times in Go's issues section, e.g.,
> https://github.com/golang/go/issues/45772#issuecomment-874616905
>
> Further head banging lead me to the discovery that
>
> xcodebuild -target WireGuardiOS -sdk iphoneos14.5
>
> actually builds successfully. I looked through the Makefile and applied some
> monkey see, monkey do. It turns out I could get it to link by adding
> GOOS_iphonesimulator := ios.

This looks a little odd to me. You should not need ios there because
the M1 is its own first class platform. About all you should need is,
ensure '-arch arm64' is used. But I probably do not understand how Go
does things.

Apple uses simulators, which means your high level C code is compiled
to the host's native instruction set. The host is where the simulator
runs. On an M1, that means code is compiled to the host's arm64
instruction set, hence the reason for '-arch arm64'. You still need to
be aware of a target SDK, but that is a particular detail. The broad
stroke is '-arch arm64' for the M1.

Android uses emulators, which means the high level C code is compiled
to the target ISA, like x86_64, arm, aarch64 or mips. Then, the ISA
instructions are interpreted on the host machine. The high level C
code is not compiled to the emulator's native instruction set.

Jeff

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [wireguard-apple] [iOS] Running WireGuard on a simulator
  2021-09-02  2:10 ` Jeffrey Walton
@ 2021-09-02  6:48   ` Neutron
  2021-09-02  7:02     ` Jeffrey Walton
  0 siblings, 1 reply; 5+ messages in thread
From: Neutron @ 2021-09-02  6:48 UTC (permalink / raw)
  To: WireGuard mailing list

Jeff, thank you for the clarification on how a simulator operates compared to an
emulator. The difference was certainly blurry in my head. I did a little more
digging and it turns out

GOOS_iphonesimulator := ios

is not required when targeting an iOS12.0 simulator. I had initially run it with
iOS14.5. Perhaps this line can be useful in the Makefile once the project's iOS
version gets bumped. Still, I would like to know why this happens.

Just like before on iOS14.5, I'm having issues with creating/editing
configurations in the simulator, with log messages like:

Saving configuration failed: Error Domain=NEVPNErrorDomain Code=5 "IPC failed"

The message I'm getting may be just as well be unrelated, but a common theme I'm
seeing is that you can't get Network Extension providers to work on simulators.
This Eskimo fellow seems to have good insight on the matter.

https://developer.apple.com/forums/thread/46004?answerId=134358022#134358022

If it really can't run on a simulator at the moment, perhaps it would be useful
for other tinkerers to see this mentioned somewhere in the README with a brief
reasoning attached. It would be a time saver, especially for those of us who are
not iOS hackers.

Neutron

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [wireguard-apple] [iOS] Running WireGuard on a simulator
  2021-09-02  6:48   ` Neutron
@ 2021-09-02  7:02     ` Jeffrey Walton
  0 siblings, 0 replies; 5+ messages in thread
From: Jeffrey Walton @ 2021-09-02  7:02 UTC (permalink / raw)
  To: WireGuard mailing list

On Thu, Sep 2, 2021 at 2:50 AM Neutron <dotneutron@protonmail.ch> wrote:
>
> Jeff, thank you for the clarification on how a simulator operates compared to an
> emulator. The difference was certainly blurry in my head. I did a little more
> digging and it turns out
>
> GOOS_iphonesimulator := ios
>
> is not required when targeting an iOS12.0 simulator. I had initially run it with
> iOS14.5. Perhaps this line can be useful in the Makefile once the project's iOS
> version gets bumped. Still, I would like to know why this happens.

Getting the environment setup correctly is tricky with Clang. With
GCC, you just run 'gcc -dumpmachine' and you can tell what you are
targeting. -dumpmachine does not work with Clang. Clang reports the
host's arch, like x86_64 even if you are targeting iPhone or
iPhoneSimulator or WatchOS or AppleTV.

To get the information from Clang you need to do something like this:
https://github.com/weidai11/cryptopp/blob/master/GNUmakefile#L50. You
have to run the preprocessor with CFLAGS or CXXFLAGS, and look for
defines like __x86_64__ or __aarch64__.

You have to use CFLAGS or CXXFLAGS because that's where you put '-arch
arm64'. Xcode sets this for you in the IDE, but you have to do it
manually when setting up a makefile.

> Just like before on iOS14.5, I'm having issues with creating/editing
> configurations in the simulator, with log messages like:
>
> Saving configuration failed: Error Domain=NEVPNErrorDomain Code=5 "IPC failed"
>
> The message I'm getting may be just as well be unrelated, but a common theme I'm
> seeing is that you can't get Network Extension providers to work on simulators.

Yeah, Apple has some cryptic error messages at times. If you can't
find it while searching, then you have to burn one of those Apple
Support incidences.

> This Eskimo fellow seems to have good insight on the matter.
>
> https://developer.apple.com/forums/thread/46004?answerId=134358022#134358022

Quinn is usually very helpful. He's been supporting Apple development
for as long as I can remember.

Jeff

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-09-02  7:06 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-02  0:57 [wireguard-apple] [iOS] Running WireGuard on a simulator Neutron
2021-09-02  1:20 ` Jeffrey Walton
2021-09-02  2:10 ` Jeffrey Walton
2021-09-02  6:48   ` Neutron
2021-09-02  7:02     ` Jeffrey Walton

Development discussion of WireGuard

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://inbox.vuxu.org/wireguard \
		wireguard@lists.zx2c4.com
	public-inbox-index wireguard

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.wireguard


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git