É um erro de tempo de execução causado por Dynamic Linker
dyld: Library not loaded: @rpath/...
...
Reason: image not found
O erro Library not loaded
com @rpath
indica que Dynamic Linker
não é possível encontrar o binário.
Verifique se a estrutura dinâmica foi adicionada ao General -> Embedded Binaries
Verifique a @rpath
configuração entre consumidor (aplicativo) e produtor (estrutura dinâmica):
- Estrutura dinâmica:
Build Settings -> Dynamic Library Install Name
- Inscrição:
Build Settings -> Runpath Search Paths
Build Phases -> Embed Frameworks -> Destination, Subpath
Vinculador dinâmico
Dynamic Library Install Name(LD_DYLIB_INSTALL_NAME)
que é usado por loadable bundle
( Dynamic framework
como derivado) onde dyld
entra em jogo
Dynamic Library Install Name
- caminho para o arquivo binário (não .framework). Sim, eles têm o mesmo nome, mas MyFramework.framework
é um packaged bundle
com MyFramework
arquivo binário e os recursos dentro.
Este caminho de directório pode ser absoluta ou relativa (por exemplo @executable_path
, @loader_path
, @rpath
). O caminho relativo é mais preferível porque é alterado juntamente com uma âncora que é útil quando você distribui seu pacote configurável como um único diretório
caminho absoluto - exemplo Framework1
//Framework1 Dynamic Library Install Name
/some_path/Framework1.framework/subfolder1
@executable_path
@executable_path - relativo à entrada binária - exemplo de
caso de uso do Framework2
: incorporar a Dynamic framework
em um aplicativo
//Application bundle(`.app` package) absolute path
/some_path/Application.аpp
//Application binary absolute path
/some_path/Application.аpp/subfolder1
//Framework2 binary absolute path
/some_path/Application.аpp/Frameworks/Framework2.framework/subfolder1
//Framework2 @executable_path == Application binary absolute path
/some_path/Application.аpp/subfolder1
//Framework2 Dynamic Library Install Name
@executable_path/../Frameworks/Framework2.framework/subfolder1
//Framework2 binary resolved absolute path by dyld
/some_path/Application.аpp/subfolder1/../Frameworks/Framework2.framework/subfolder1
/some_path/Application.аpp/Frameworks/Framework2.framework/subfolder1
@loader_path
@loader_path - relativo ao pacote configurável que é proprietário deste
caso de uso binário : framework com framework incorporado - Framework3_1 com Framework3_2 dentro
//Framework3_1 binary absolute path
/some_path/Application.аpp/Frameworks/Framework3_1.framework/subfolder1
//Framework3_2 binary absolute path
/some_path/Application.аpp/Frameworks/Framework3_1.framework/Frameworks/Framework3_2.framework/subfolder1
//Framework3_1 @executable_path == Application binary absolute path
/some_path/Application.аpp/subfolder1
//Framework3_1 @loader_path == Framework3_1 @executable_path
/some_path/Application.аpp/subfolder1
//Framework3_2 @executable_path == Application binary absolute path
/some_path/Application.аpp/subfolder1
//Framework3_2 @loader_path == Framework3_1 binary absolute path
/some_path/Application.аpp/Frameworks/Framework3_1.framework/subfolder1
//Framework3_2 Dynamic Library Install Name
@loader_path/../Frameworks/Framework3_2.framework/subfolder1
//Framework3_2 binary resolved absolute path by dyld
/some_path/Application.аpp/Frameworks/Framework3_1.framework/subfolder1/../Frameworks/Framework3_2.framework/subfolder1
/some_path/Application.аpp/Frameworks/Framework3_1.framework/Frameworks/Framework3_2.framework/subfolder1
@rpath - Caminho de pesquisa do caminho da execução
Exemplo de Framework2
Anteriormente, tínhamos que configurar um Framework para trabalhar com dyld. Não é conveniente porque o mesmo Framework não pode ser usado com configurações diferentes
@rpath
é um conceito composto que se baseia em partes externas (Aplicativo) e aninhadas (Estrutura dinâmica):
Inscrição:
Estrutura dinâmica:
//Application Runpath Search Paths
@executable_path/../Frameworks
//Framework2 Dynamic Library Install Name
@rpath/Framework2.framework/subfolder1
//Framework2 binary resolved absolute path by dyld
//Framework2 @rpath is replaced by each element of Application Runpath Search Paths
@executable_path/../Frameworks/Framework2.framework/subfolder1
/some_path/Application.аpp/Frameworks/Framework2.framework/subfolder1
* ../
- vá para o pai do diretório atual
otool
- ferramenta de exibição de arquivo de objeto
//-L print shared libraries used
//Application otool -L
@rpath/Framework2.framework/subfolder1/Framework2
//Framework2 otool -L
@rpath/Framework2.framework/subfolder1/Framework2
//-l print the load commands
//Application otool -l
LC_LOAD_DYLIB
@rpath/Framework2.framework/subfolder1/Framework2
LC_RPATH
@executable_path/../Frameworks
//Framework2 otool -l
LC_ID_DYLIB
@rpath/Framework2.framework/subfolder1/Framework2
install_name_tool
alterar nomes de instalação dinâmicos da biblioteca compartilhada usando -rpath
CocoaPods
usa use_frameworks!
[Sobre] para regular umDynamic Linker
[Vocabulário]
Link Binary with Libraries
e, de alguma forma, o Xcode sabe copiá-las no pacote de aplicativos, enquanto que para estruturas personalizadas isso simplesmente não acontece.