Issues running tests with Xcode 12

[dimitribouniol]

I'm not sure if anyone else (👋 @kirilltitov) has run into this, but I cannot run tests when the package is built using Xcode 12. The following errors are reported, indicating the test target cannot find libfdb_c.dylib:

2020-10-08 12:43:14.476787-0700 xctest[82265:4451631] The bundle “FDBTests” couldn’t be loaded because it is damaged or missing necessary resources. Try reinstalling the bundle.
2020-10-08 12:43:14.476968-0700 xctest[82265:4451631] (dlopen_preflight(/Users/dimitribouniol/Library/Developer/Xcode/DerivedData/FDBSwift-avmdmjjucugpndfvczrsqjfgiexd/Build/Products/Debug/FDBTests.xctest/Contents/MacOS/FDBTests): Library not loaded: libfdb_c.dylib
  Referenced from: /Users/dimitribouniol/Library/Developer/Xcode/DerivedData/FDBSwift-avmdmjjucugpndfvczrsqjfgiexd/Build/Products/Debug/FDBTests.xctest/Contents/MacOS/FDBTests
  Reason: image not found)
Program ended with exit code: 82

This extends to packages that depend on FDBSwift. Running the tests via SwiftPM (Swift 5.3) directly runs the tests fine. Building and running an app that depends on FDBSwift via Xcode also works fine.

I initially though this could have something to do with systemLibrary support in SwiftPM, so I made a bare-bones package that imported libfdb, and saw the same issues. However, switching the library to libevent (A random pkgConfig I had installed on my system) built and ran the tests fine, so I think it may be specific to the fdb pkgConfig?

Here is the libevent.pc:

#libevent pkg-config source file

prefix=/usr/local/Cellar/libevent/2.1.11_1
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: libevent
Description: libevent is an asynchronous notification event loop library
Version: 2.1.11-stable
Requires:
Conflicts:
Libs: -L${libdir} -levent
Libs.private: 
Cflags: -I${includedir}

Compared to my libfdb.pc:

prefix=/usr/local
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib

Name: fdb
Description: FoundationDB macOS library
Version: 6.2.22
Cflags: -I${includedir}
Libs: -L${libdir} -lfdb_c

I'd appreciate any pointers if it seems I'm doing something wrong, or if this is reproducible at all...

[kirilltitov]

Yeah, I've run into this one too. I tend to believe that it is an Xcode bug, bc SPM/Linux works like a charm, AND running a product in Xcode that has FDB as a dependency, works as well. I haven't tried opening it as xcodeproj (I've been only using Package.swift lately).

Maybe it has something to do with unsigned FoundationDB distributions — last time I downloaded it from official website, it refused to install client/server because of unsigned (or incorrectly signed? can't remember) .pkg installation file.

Luckily, it's not a blocker ATM, so we can at least monitor/investigate the problem, or maybe it will go away as we update to Big Sur or newer Xcode version :)

(BTW, Dimitri, I'm going to release something FDB-related in a few days, stay tuned, I think you gonna like it :)

[dimitribouniol]

I've only been using Package.swift via Xcode as well, so needing to switch to the terminal to run tests is a bit different than what I'm used to, so I was hoping it was just me 😅

(BTW, Dimitri, I'm going to release something FDB-related in a few days, stay tuned, I think you gonna like it :)

Looking forward to it!

Btw, I was hoping there would be a slack/discord for FDB/Swift discussion - is there one I don't know about? Would the swift-server.slack.com folks mind if there was a channel specific to it?

[kirilltitov]

I think it's totally an Xcode bug, it just yielded a warning: ld: warning: dylib (/usr/local/lib/libfdb_c.dylib) was built for newer macOS version (10.14) than being linked (10.10)

[dimitribouniol]

Still broken in 12.1, so I filed feedback: FB8820195

[kirilltitov]

Yeah, I think Xcode now requires all dylibs to be signed (unlike regular console Swift/SPM), whereas libfdb_c is not :/ Small_indie_company.jpg

[dimitribouniol]

le sigh

[dimitribouniol]

And I solved it!

The magic incantation: $ install_name_tool -id /usr/local/lib/libfdb_c.dylib /usr/local/lib/libfdb_c.dylib

How I got there: $ otool -L /usr/local/lib/libfdb_c.dylib gives:

/usr/local/lib/libfdb_c.dylib:
    libfdb_c.dylib (compatibility version 0.0.0, current version 0.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1560.0.0)
    /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)

but for almost any other dylib, the id (first entry) is a full path. Those packages imported just fine, while libfdb_c.dylib did not. install_name_tool fixes this. I'll be opening an issue on the FoundationDB repo to report this, so leaving this open in case we want to add the install_name_tool command to the install script.

[kirilltitov]

Wow, now that the investigation :D

[kirilltitov]

I decided to include this magic command to install_pkgconfig.sh. And also confirmed that this library works perfectly (well almost) with Apple Silicon. As for FDB itself... Oh welp, at least first pre-release of 7.0.0 was published yesterday (not pkg tho). And you can always build it from source :)

[dimitribouniol]

Glad to see FDB releases still have not fixed this 🙃