Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-272] Linker error: Undefined reference to _TFC10Foundation8NSObjectg9_cfTypeIDSu #42894

Closed
briancroom opened this issue Dec 17, 2015 · 15 comments
Closed

[SR-272] Linker error: Undefined reference to _TFC10Foundation8NSObjectg9_cfTypeIDSu #42894

briancroom opened this issue Dec 17, 2015 · 15 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@briancroom
Copy link
Collaborator

Previous ID SR-272
Radar None
Original Reporter @briancroom
Type Bug
Status Closed
Resolution Done
Environment

OS: Ubuntu 14.04
Swift version: Toolchain snapshot from December 10

$ swift --version
Swift version 2.2-dev (LLVM 7bae82deaa, Clang 53d04af5ce, Swift 5995ef2acd)
Target: x86_64-unknown-linux-gnu
$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.24
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee Bikineev (JIRA)
Priority Medium

md5: 3160ace0e7f5b64d6d2e37dcd2edff86

relates to:

  • SR-1129 Linker step fails when subclassing a class with a 'public private(set) var'

Issue Description:

I am encountering an undefined symbol error when building an executable which contains an NSObject subclass. A minimal example is:

import Foundation
class MyObject: NSObject {}

When that code is put into main.swift and an empty Package.swift, running the build tool creates the following output:

$ swift build -v
/home/osboxes/swift/swift-2.2-SNAPSHOT-2015-12-10-a-ubuntu14.04/usr/bin/swiftc -module-name LetsTryFoundation -incremental -emit-dependencies -emit-module -emit-module-path /home/osboxes/swift/LetsTryFoundation/.build/debug/LetsTryFoundation.swiftmodule -output-file-map /home/osboxes/swift/LetsTryFoundation/.build/debug/LetsTryFoundation.o/LetsTryFoundation/output-file-map.json -c /home/osboxes/swift/LetsTryFoundation/Sources/main.swift -I /home/osboxes/swift/LetsTryFoundation/.build/debug -j8 -Onone -g -I /usr/local/include
/home/osboxes/swift/swift-2.2-SNAPSHOT-2015-12-10-a-ubuntu14.04/usr/bin/swiftc -o /home/osboxes/swift/LetsTryFoundation/.build/debug/LetsTryFoundation /home/osboxes/swift/LetsTryFoundation/.build/debug/LetsTryFoundation.o/Sources/main.swift.o -g -L/usr/local/lib
/home/osboxes/swift/LetsTryFoundation/.build/debug/LetsTryFoundation.o/Sources/main.swift.o:(.data.rel+0xa8): undefined reference to `_TFC10Foundation8NSObjectg9_cfTypeIDSu'
/usr/bin/ld: /home/osboxes/swift/LetsTryFoundation/.build/debug/LetsTryFoundation: hidden symbol `_TFC10Foundation8NSObjectg9_cfTypeIDSu' isn't defined
/usr/bin/ld: final link failed: Bad value
clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: link command failed with exit code 1 (use -v to see invocation)
<unknown>:0: error: build had 1 command failures
swift-build: exit(1): ["/home/osboxes/swift/swift-2.2-SNAPSHOT-2015-12-10-a-ubuntu14.04/usr/bin/swift-build-tool", "-v", "-f", "/home/osboxes/swift/LetsTryFoundation/.build/debug/LetsTryFoundation.o/llbuild.yaml"]

Note that the build succeeds if I only use NSObject subclasses that are defined in Foundation. The error only occurs when creating a new NSObject subclass in my code. The motivation for subclassing NSObject is to allow the code to compile unchanged on Mac and Linux.

It's not immediately obvious to me whether this is an bug with swift-package-manager generating an incorrect build command, a symbol visibility problem in swift-corelibs-foundation, or a linker issue.
@belkadan
Copy link
Contributor

Sounds like a compiler bug; even though _cfTypeID is internal to Foundation, it still needs to be available for subclass vtables.

@mxcl
Copy link

mxcl commented Dec 21, 2015

Just FYI: works on Darwin.

@lhoward
Copy link
Contributor

lhoward commented Dec 29, 2015

I am also seeing this with the current snapshot and Foundation built from source.

@phausler
Copy link
Member

we can change _cfTypeID to a function instead of a property if that helps. NSObject should not have any variables since it would screw up the NSCF type layouts

@lhoward
Copy link
Contributor

lhoward commented Dec 29, 2015

This issue is no longer blocking me as I can test conforming to NSCoding without subclassing from NSObject (notwithstanding other issues).

Edit: it is a blocker because it does appear you need to inherit from NSObject to be codeable.

@lhoward
Copy link
Contributor

lhoward commented Dec 30, 2015

Changing _cfTypeID to a function does not help.

hidden symbol `_TFC10Foundation8NSObject9_cfTypeIDfT_Su' isn't defined

@belkadan
Copy link
Contributor

belkadan commented Jan 4, 2016

I think the workaround would be temporarily making it public rather than changing what kind of declaration it is. Sorry for not actually saying that above.

@lhoward
Copy link
Contributor

lhoward commented Jan 4, 2016

Pull request coming up. I assume changing the visibility won't add storage requirements that would break CF bridging?

@lhoward
Copy link
Contributor

lhoward commented Jan 4, 2016

apple/swift-corelibs-foundation#215

@phausler
Copy link
Member

phausler commented Jan 4, 2016

We should probably make an additional bug to track making this API internal

@phausler
Copy link
Member

phausler commented Jan 4, 2016

https://bugs.swift.org/browse/SR-464

@briancroom
Copy link
Collaborator Author

Going ahead and closing this since the original issue has been fixed. Thanks!

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 2, 2016

> I think the workaround would be temporarily making it public

Is there a task tracking the underlying bug? swift-corelibs-xctest now has several variables marked as public purely to work around this issue.

I couldn't find any existing bugs after a few searches, so I'm going to create my own--please point me to any existing issues if you know of them, though!

@modocache
Copy link
Mannequin

modocache mannequin commented Apr 3, 2016

I filed https://bugs.swift.org/browse/SR-1129 to track fixing the underlying cause of these workarounds.

@modocache
Copy link
Mannequin

modocache mannequin commented May 12, 2016

swift-corelibs-xctest continues to work around this issue; several access modifiers included in apple/swift-corelibs-xctest#109 have been marked public in order to avoid a compiler segfault.

I'd love it if someone could have a closer look at https://bugs.swift.org/browse/SR-1129 – it doesn't seem to be prioritized, but it causes us a lot of pain. If someone could chime in on that issue, either with a fix or with some pointers on where to start looking in order to diagnose the issue, that'd be much appreciated!!

I added a test that demonstrates this issue to the Swift test suite in #2039 – it is fairly easy to reproduce. 🙂

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@mxcl @phausler @lhoward @belkadan @briancroom