Charts: Undefined symbol: method descriptor for Charts.ChartViewBase.initialize() -> ()

[wysiek]

I got the error when I try to do archive, any ideas?

*Xcode version:10.2.1
*Swift version:4.2
*Platform(s) running Charts:iOS
*macOS version running Xcode: 10.14.4

[kemchenj]

@liuxuan30 I create a demo that can reproduce this compile error. Clone the repo and run this command in command line:

pod install && xcodebuild -workspace Demo.xcworkspace -scheme Demo | xcpretty

And compiler will throw an error like this:

▸ Linking Demo

❌  Undefined symbols for architecture arm64
> Symbol: method descriptor for Charts.ChartViewBase.initialize() -> ()
> Referenced from: l_got.$s6Charts13ChartViewBaseC10initializeyyFTq in ViewController.o

❌  ld: symbol(s) not found for architecture arm64

❌  clang: error: linker command failed with exit code 1 (use -v to see invocation)

This is a simple demo, the only thing I've done is subclassing CombinedChartView and override the initialize method.

I think it is caused by the access level of initialize method, it was marked as internal in ChartViewBase and open in CombinedChartView, somehow swift compiler could not work well with these kind of code.

[ajain26]

hi,

Please unsubscribe me from this service

On Mon, Apr 29, 2019 at 6:35 AM Kem Chen [e-mail] wrote:

@liuxuan30 https://github.com/liuxuan30 I create a demo
https://github.com/kemchenj/ChartsDemo to reproduce this compile error.
Clone the repo and run this command in command line:

pod install && xcodebuild -workspace Demo.xcworkspace -scheme Demo | xcpretty

And compiler will throw an error like this:

▸ Linking Demo

❌ Undefined symbols for architecture arm64

Symbol: method descriptor for Charts.ChartViewBase.initialize() -> ()

Referenced from: l_got.$s6Charts13ChartViewBaseC10initializeyyFTq in ViewController.o

❌ ld: symbol(s) not found for architecture arm64

❌ clang: error: linker command failed with exit code 1 (use -v to see invocation)

This is a simple demo, the only I've done is subclassing CombinedChartView
and override the initialize method.

The access level of initialize method was marked as internal in
ChartViewBase and open in CombinedChartView. It looks like a bug from
swift compiler.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/danielgindi/Charts/issues/3976#issuecomment-487430932,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACUFPYHBOYM6CQA7MTCZFNTPSZCWFANCNFSM4HI26WBQ
.

[liuxuan30]

I don't know why, but the master builds well. So I can only assume it's your build setting issues. Turn to Stack overflow for more help.

[downie]

I'm also running into this problem.

[nickwph]

I also had this issue after upgrading my Xcode to 10.2.1. Speculation of @kemchenj is correct and I just modified all internal override func initialize() -> open override func initialize() in the following files. Then I can build without issues.

Pods/Charts/Source/Charts/Charts/BarChartView.swift
Pods/Charts/Source/Charts/Charts/BarLineChartViewBase.swift
Pods/Charts/Source/Charts/Charts/CandleStickChartView.swift
Pods/Charts/Source/Charts/Charts/ChartViewBase.swift
Pods/Charts/Source/Charts/Charts/HorizontalBarChartView.swift
Pods/Charts/Source/Charts/Charts/LineChartView.swift
Pods/Charts/Source/Charts/Charts/PieChartView.swift
Pods/Charts/Source/Charts/Charts/PieRadarChartViewBase.swift
Pods/Charts/Source/Charts/Charts/RadarChartView.swift 

Please don't close this issue and look into it

[jeremy-w]

Yes. It doesn't show during Debug builds if "enable testability" is on. It seems to be a bug, since that ought to work:

An override can make an inherited class member more accessible than its superclass version. (https://docs.swift.org/swift-book/LanguageGuide/AccessControl.html#ID16)

But it may be telling that the example in the docs is going from fileprivate to internal, not internal to public.

The workaround is not to override initialize from the subclass, but do work in init or another method.

If it's desired to continue to support hooking initialize, an explicitly public hook could be added (doInitialize or beforeInitialize/afterInitialize pairs), or probably upgrading initialize to be open all the way through the library will fix it. (Or maybe Swift vNext will fix this. 🤞 )

[downie]

For the curious, here's an open radar of the bug I submitted to Apple: http://www.openradar.me/radar?id=6072265754017792

[downie]

That radar has been closed as a dupe, but it looks like the underlying access issue might be fixed in Swift 5.1. https://github.com/apple/swift/pull/25190