Closed dimitribouniol closed 2 years ago
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 :)
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?
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)
Still broken in 12.1, so I filed feedback: FB8820195
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
le sigh
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.
Wow, now that the investigation :D
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 :)
Glad to see FDB releases still have not fixed this 🙃
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
: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
:Compared to my
libfdb.pc
:I'd appreciate any pointers if it seems I'm doing something wrong, or if this is reproducible at all...