Troubles running benchmarks and locally built swift

Development Compiler
1

After upgrading my machine to Mojave because the master started to require Xcode 10.2-beta and after overcoming the initial troubles, I have managed to successfully complete the local swift build. But now I am unable to use the resulting binaries in the usual way from /Users/mondo/Developer/swift-source/build/Ninja-Release/swift-macosx-x86_64/bin:

$ ./Benchmark_O 1
dyld: lazy symbol binding failed: Symbol not found: _objc_setHook_getClass
  Referenced from: /Users/mondo/Developer/swift-source/build/Ninja-Release/swift-macosx-x86_64/bin/../lib/swift/macosx/libswiftCore.dylib
  Expected in: /usr/lib/libobjc.A.dylib

dyld: Symbol not found: _objc_setHook_getClass
  Referenced from: /Users/mondo/Developer/swift-source/build/Ninja-Release/swift-macosx-x86_64/bin/../lib/swift/macosx/libswiftCore.dylib
  Expected in: /usr/lib/libobjc.A.dylib

Abort trap: 6

and

$ ./swift
dyld: lazy symbol binding failed: Symbol not found: _objc_setHook_getClass
  Referenced from: /Users/mondo/Developer/swift-source/build/Ninja-Release/swift-macosx-x86_64/lib/swift/macosx/libswiftCore.dylib
  Expected in: /usr/lib/libobjc.A.dylib

dyld: Symbol not found: _objc_setHook_getClass
  Referenced from: /Users/mondo/Developer/swift-source/build/Ninja-Release/swift-macosx-x86_64/lib/swift/macosx/libswiftCore.dylib
  Expected in: /usr/lib/libobjc.A.dylib

Stack dump:
0.	Program arguments: /Users/mondo/Developer/swift-source/build/Ninja-Release/swift-macosx-x86_64/bin/swift -frontend -repl -enable-objc-interop -sdk /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -color-diagnostics -module-name REPL 
1.	while processing REPL source:
0  swift                    0x0000000112d000f5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1  swift                    0x0000000112cff298 llvm::sys::RunSignalHandlers() + 248
2  swift                    0x0000000112d00702 SignalHandler(int) + 258
3  libsystem_platform.dylib 0x00007fff61d1cb3d _sigtramp + 29
4  libsystem_platform.dylib 0x00007ffee05b3690 _sigtramp + 2122935152
5  libsystem_platform.dylib 0x0000000117839c7f _sigtramp + 3048329567
6  libsystem_platform.dylib 0x00000001177f7aea _sigtramp + 3048058826
7  libsystem_platform.dylib 0x00000001177f7c17 _sigtramp + 3048059127
8  libdyld.dylib            0x00007fff61b1dc1a dyld_stub_binder + 282
9  libswiftCore.dylib       0x0000000116761008 GCC_except_table1 + 43300
10 libswiftCore.dylib       0x000000011780bec6 GCC_except_table1 + 17520610
11 libswiftCore.dylib       0x00000001178070da GCC_except_table1 + 17500662
12 libswiftCore.dylib       0x0000000117806254 GCC_except_table1 + 17496944
13 libswiftCore.dylib       0x00000001178062e8 GCC_except_table1 + 17497092
14 libswiftCore.dylib       0x00000001177f8d20 GCC_except_table1 + 17442364
15 libswiftCore.dylib       0x000000011780275f GCC_except_table1 + 17481851
16 libdyld.dylib            0x00007fff61b1d62f dlopen + 200
17 swift                    0x000000010f6bb9be loadRuntimeLib(llvm::StringRef) + 158
18 swift                    0x000000010f6ba133 loadRuntimeLib(llvm::StringRef, llvm::StringRef) + 227
19 swift                    0x000000010f6bdb2d REPLEnvironment::REPLEnvironment(swift::CompilerInstance&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, llvm::LLVMContext&, bool) + 1453
20 swift                    0x000000010f6bbdca swift::runREPL(swift::CompilerInstance&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, bool) + 58
21 swift                    0x000000010f696096 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*, swift::UnifiedStatsReporter*) + 2902
22 swift                    0x000000010f69494e swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 2990
23 swift                    0x000000010f643636 main + 662
24 libdyld.dylib            0x00007fff61b31ed9 start + 1
25 libdyld.dylib            0x0000000000000009 start + 2655838513
Killed: 9

Can somebody please help me get back to a working locally built swift and benchmarks in this brave new ABI-stable world? I must have missed the memo… :cry:

2

I must have missed the memo as well. I suspect @Mike_Ash knows the answer. Are you on 10.14.3?

3

I’m on macOS Mojave 10.14.3, Xcode 10.2 Beta 2.

4

Uh, hm. If it's not weak-linking this symbol, you can temporarily change the !OBJC_GETCLASSHOOK_DEFINED to 0 in stdlib/public/runtime/MetadataLookup.cpp. (See Sign in to GitHub · GitHub)

5

:pleading_face: What is going on? I thought I would have to set some ENV variables or something...

6

If it's what I think it is, the ObjC runtime function is being defined with the wrong availability…

…which means the Swift runtime is strong-linking to it instead of weak-linking, meaning it must be there when you run…

…and this macro opts back into the workaround for before it was added to the headers in the public SDK.

What I don't understand is why it's only failing for you, so hopefully Mike can shed some light on that.

7

I had similar linking issues a few months ago. The only thing that worked for me was a clean install of macOS.

8

Replacing the 2 occurrences of !OBJC_GETCLASSHOOK_DEFINED with a hardcoded 1 in MetadataLookup.cpp made the local build executable again for me! :clap::tada:

I'm a little hesitant to go for clean OS re-install to verify if that would also fix the issue, as it's a major work disruption. Is that something that would help you? I have to admit that I'm on an unsupported HW configuration and this machine has had in-place OS upgrades since 10.5.5...:angel:

9

I agree that it's due to the wrong availability. Because the availability annotation says 10.14 instead of 10.14.4, I believe the compiler will incorrectly conclude that it must be available when your deployment target is 10.14.0-3 and thus not weak-link it. It'll work properly with older or newer deployment targets.

It will take some time to get the availability annotation fixed in the ObjC header. In the meantime, we should have Swift manually redeclare the function to force a weak import or something like that.

10

OK, for now I'm getting a workable build with the patch Jordan suggested, tough it's a bit tedious to discard the local changes and re-apply it from stash on every git commit and rebase. Will this resolve itself with time (next OS point release?) or is there something I should do to get a permanent solution?