Ошибка lldb: не удалось найти символы. Свифт iOS

С помощью lldb я хочу создать экземпляр класса Swift в моей динамической структуре сборки и выпуска iOS.

Я прикрепляю lldb к своей сборке выпуска на симуляторе.

Основное приложение - работает

(lldb) exp let $c = hello_class()
error: <EXPR>:3:10: error: use of unresolved identifier 'hello_class'
let $c = hello_class()
         ^~~~~~~~~~~
(lldb) expr import My_App
(lldb) exp let $c = hello_class()
(lldb) po $c.hello()
? hello ?

динамический каркас - не работает

(lldb) dclass -m myframework
Dumping classes
************************************************************
myframework.RustyAppInfo

(lldb) expr import myframework
(lldb) expr let $d = RustyAppInfo()
error: Couldn't lookup symbols:
  __T011myframework12RustyAppInfoCACycfC

И приложение, и динамический фреймворк были созданы без оптимизации.

ОБНОВИТЬ

статическая структура - не работает

Те же результаты при переходе - на введенную функцию Xcode 9 - статическую структуру Swift.

Xcode - удаление мертвого кода

по умолчанию с кодом Swift Dead Code Stripping включен. Я проверил, не в этом ли проблема. Никакой разницы в результатах.

Интересно! Может быть, отредактируйте вопрос, чтобы он содержал «из фреймворка при подключении его в отладчике» или так, чтобы быть более конкретным и, надеюсь, привлечь специалистов :)

ctietze 18.07.2018 09:41

Этот символ: myframework.RustyAppInfo.__allocating_init() -> myframework.RustyAppInfo. Это кажется разумным вызовом при создании нового объекта, но я не уверен, почему его нет в вашем фреймворке.

Jim Ingham 19.07.2018 01:27

Мне не удалось объявить функцию инициализации моей Framework как общедоступную @JimIngham. Это было причиной того, что не удалось найти символ.

rustyMagnet 27.07.2018 11:24
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
7
3
8 195
1

Ответы 1

РЕШЕНО

Я нашел свой ответ в этой статье:

http://iosbrain.com/blog/2018/01/13/building-swift-4-frameworks-and-including-them-in-your-apps-xcode-9/

Мне не удалось установить public init() в классе Swift, который находился внутри Framework. Рабочий код, который может быть вызван lldb:

// set the Framework class to Public
public class rnHello{  

   // set the initializer to public, otherwise you cannot invoke class
    public init() {  

    }

    // set the function to public, as it defaults to internal
    public static func world() {  
        print("hello from a static method")
    }
}

Теперь вы можете получить к нему доступ через свой Swift-код или с помощью lldb:

(lldb) po rnHello.world()
hello from a static method

Обратите внимание, проблема заключалась не в том, что метод был частным сам по себе. Анализатор выражений lldb может вызывать методы независимо от того, являются они общедоступными или частными. Проблема заключалась в том, что, поскольку init не был общедоступным, компилятор знал, что он может рассуждать обо всех его применениях, и поэтому ему не нужно было генерировать неиспользуемые ароматы, включая тот, который ему нужен для создания объекта из lldb. Когда вы делаете init общедоступным, swift больше не может рассуждать о его использовании, а вместо этого должен выдавать все, что может быть вызвано.

Jim Ingham 01.08.2018 19:53

Другие вопросы по теме