Wierd problem with swift-perception dependency

[doozMen]

Linux/Cross-Platform Compatibility: Swift-Perception Dependency Issue

Use Case

We're developing a cross-platform desktop application in Swift that needs to run on macOS, Linux, and Windows. We're using swift-structured-queries for its excellent type safety and refactoring capabilities with our SQLite database.

However, swift-structured-queries is just a query builder - it doesn't include a database driver. This is where sharing-grdb comes in: it provides the perfect integration between swift-structured-queries and GRDB (the SQLite driver). Unfortunately, we cannot use sharing-grdb due to a Linux compatibility issue.

The Challenge

We discovered that sharing-grdb depends on swift-sharing, which in turn depends on swift-perception. This creates a blocking issue for Linux deployment:

sharing-grdb → swift-sharing → swift-perception

When building on Linux, we encounter linking errors:

/usr/lib/swift/linux/libswiftObservation.so: error: undefined reference to 'swift::threading::fatal(char const*, ...)'

The swift-perception library backports Apple's Observation framework to older platforms, but this involves platform-specific code that doesn't compile properly on Linux.

The Puzzling Part

What's particularly confusing is that all these libraries individually build and test successfully on Linux:

• ✅ swift-structured-queries has Linux CI that passes
• ✅ sharing-grdb has Linux CI that passes
• ✅ swift-sharing has Linux CI that passes
• ✅ swift-perception has Linux CI that passes

However, when integrated into our application, the linking fails. We believe this happens because:

1. Library CI tests may not exercise the problematic code paths - The tests might not trigger the Observation-related code that causes the linking error
2. The error references an internal Swift runtime function - swift::threading::fatal appears to be an internal API that exists on Darwin but isn't properly exported on Linux
3. Transitive dependency linking - Even though we don't use the SwiftUI features, the linker still needs to resolve all symbols from all transitive dependencies
4. Different build configurations - CI might use different toolchain versions or linker flags that mask the issue

This suggests the problem isn't with the individual libraries per se, but with how the Observation backport in swift-perception relies on platform-specific internals that aren't available in all Linux deployment scenarios.

Our Current Workaround

Since we need swift-structured-queries to work with GRDB but cannot use sharing-grdb due to the Linux linking issue, we've had to implement our own integration layer. This includes:

• Converting QueryFragment to GRDB statements
• Mapping QueryBinding to DatabaseValue
• Implementing fetchAll(), fetchOne(), and execute() methods
• Creating a QueryDecoder for result mapping

This feels like reinventing the wheel when sharing-grdb already provides this exact functionality in a battle-tested implementation. We would much prefer to use sharing-grdb if it could work on Linux.

Proposed Solution

We'd like to discuss the possibility of making the swift-sharing dependency optional or creating a variant that doesn't require it. From our analysis:

1. The swift-sharing dependency appears to be primarily used for SwiftUI integration (@SharedReader, @Fetch property wrappers)
2. The core functionality in StructuredQueriesGRDBCore doesn't seem to require these SwiftUI features
3. Server-side and CLI applications don't need the reactive UI bindings

Potential Approaches

1. Conditional Compilation: Add #if !os(Linux) && canImport(SwiftUI) guards around SwiftUI-specific code
2. Separate Targets: Create a StructuredQueriesGRDBCoreLinux target without SwiftUI dependencies
3. Feature Flags: Make the SwiftUI integration opt-in via a feature flag

Questions

• Would the maintainers be open to a PR that adds Linux compatibility?
• Is there a preferred approach from the options above?
• Are there any hidden dependencies on swift-sharing that we might have missed?

We're happy to contribute a PR if this aligns with the project's goals. The ability to use sharing-grdb on Linux would be valuable for the growing Swift-on-server and cross-platform desktop community.

Thank you for creating this excellent integration between swift-structured-queries and GRDB! It's exactly what we need - we just need it to work on Linux without the SwiftUI dependencies.

[mbrandonw]

Hi @doozMen, thanks for taking the time to report this, but unfortunately the assessment in your report seems to be wrong. The error in your report:

/usr/lib/swift/linux/libswiftObservation.so: error: undefined reference to 'swift::threading::fatal(char const*, ...)'

…lives in libswiftObservation.so, which is not something from our libraries. Also your report states that each of the libraries involved build for Linux just fine, which they do.

And finally, your report specifically glosses over the solution:

The core functionality in StructuredQueriesGRDBCore doesn't seem to require these SwiftUI features

The StructuredQueriesGRDBCore library in this package specifically does not depend on Sharing or Perception:

https://github.com/pointfreeco/sharing-grdb/blob/86165c79ffcfc2472779060d718887067a5252f6/Package.swift#L62-L70

So, you can use that library instead of SharingGRDB.

Additionally, it is clear that you used AI to generate this report. We'd appreciate in the future that you at least provide a disclaimer that you have done so, but also we'd prefer you to just write the report yourself. This AI generated report includes many superfluous details that take up our time to read and think through. It's just really wasteful, and so in the future please take the time to minimize the discussion in your own words.

[aehlke]

@doozMen have you since been able to get this working under Linux?

[stephencelis]

@aehlke I don't believe GRDB makes any guarantees of compiling on Linux, and I don't believe the latest version (7.6.1) compiles successfully on Linux (we had to disable Linux CI because of this).

We'd be happy to take any patches that aid in Linux support, but we aren't focused on that platform ourselves.