Symbol not found: _kdebug_signpost_start

Mobile Couchbase Lite
1

Hi,

I’m having a problem. I have compiled couchbase lite core on a Mac OSX 10.13 system, but it crashes when executed on systems with 10.10 and 10.11 because the symbol _kdebug_signpost_start doesn’t exist. Is there any way of avoiding the link with the _kdebug_signpost_start? Stack trace below.

Symbol not found: _kdebug_signpost_start
Expected in: /usr/lib/libSystem.B.dylib

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 0x00007fff6a0dc075 dyld_fatal_error + 1
1 0x00007fff6a0df094 dyld::fastBindLazySymbol(ImageLoader**, unsigned long) + 139
2 0x00007fff9f6d7262 dyld_stub_binder + 282
3 0x000000010505b008 0 + 4379226120
4 0x0000000102f5ddc5 c4Internal::Database::Database(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, C4DatabaseConfig) + 1141
5 0x00000001030c6ed0 c4Database* fleece::function_ref<c4Database* ()>::callback_fn<c4db_open::$_0>(long) + 240
6 0x00000001030c62be c4Database* c4Internal::tryCatch<c4Database*>(C4Error*, fleece::function_ref<c4Database* ()>) + 14
7 0x00000001030c62a7 c4db_open + 39

Thanks in advance!

Best regards,

Nuno

2

Signposts were added in macOS 10.12. A quick scan of the code shows you might be able to undefine LITECORE_SIGNPOSTS in LiteCore/Support/Instrumentation.hh

3

@Grimal, thanks for your reply. I have search the code and found that too. I was wondering if I could do that with no consequences what so ever.

Thanks!

Regards,

Nuno

4

Signposts exist only for profiling, and have no effect on the actual library functionality. You won’t notice a difference with them gone unless you are profiling inside of Xcode instruments.

5

Thanks @borrrden! Best

6

The _kdebug_sign_post was fixed. Now I have other:

Dyld Error Message:
Symbol not found: _dispatch_queue_attr_make_with_autorelease_frequency

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 dyld 0x00007fff6cbd2075 dyld_fatal_error + 1
1 dyld 0x00007fff6cbd5094 dyld::fastBindLazySymbol(ImageLoader**, unsigned long) + 139
2 libdyld.dylib 0x00007fff99105262 dyld_stub_binder + 282
3 ??? 0x0000000105387008 0 + 4382552072
4 com.imaginando.drc 0x000000010347da0e litecore::blip::BLIPIO::BLIPIO(litecore::blip::Connection*, litecore::websocket::WebSocket*, litecore::blip::Deflater::CompressionLevel) + 254
5 com.imaginando.drc 0x000000010347c9ca litecore::blip::Connection::Connection(litecore::websocket::WebSocket*, fleece::AllocedDict const&, litecore::blip::ConnectionDelegate&) + 298

Are we able to safely avoid this one?

7

Our calls to the signpost API and dispatch_queue_attr_make_with_autorelease_frequency are conditionalized with __builtin_available, and we’ve set the macOS deployment target to 10.11, so I don’t understand why there’d be any runtime problem on 10.10.

8

Commenting out that line should be OK. I think that call is just a small optimization, nothing noticeable on its own.

9

@jens,

What I have done to build couchbase-lite-core was simply calling the build_macos.sh script without any kind of parameters. Those calls are protected with: if (__builtin_available(macOS 10.12, iOS 10, tvOS 10)) but they are definitely being included as I have built this on a Mac OS 10.13 system. I had to comment in four different places:

a) LiteCore/Support/Instrumentation.hh - #define LITECORE_SIGNPOSTS 0
b) LiteCore/Support/FilePath.cc
c) vendor/BLIP-Cpp/src/util/Codec.cc
d) vendor/BLIP-Cpp/src/util/GCDMailbox.cc

I would prefer to not hack the files everytime I need to rebuild couchbase-lite-core.

Is there any way of specifying the target deployment system?

Best regards,

Nuno

10

Edit Project.xcconfig (there’s one in LiteCore and one in vendor/BLIP_Cpp) and change MACOSX_DEPLOYMENT_TARGET. But it’s already set to 10.11, so I don’t know why the binary is non-weak linking against symbols added in 10.12.

11

Confirmed, BlipCpp is using MACOSX_DEPLOYMENT_TARGET = 10.11

The fact is, it is using those symbols anyway.

12

Does couchbase-lite-core/build_cmake/scripts/build_macos.sh use this settings?

13

Yes. It uses the xcodebuild tool, which runs exactly the same build system as Xcode.