Usando otool (recursivamente) para encontrar as bibliotecas compartilhadas necessárias para um aplicativo
-
19-09-2019 - |
Pergunta
Eu tenho um aplicativo de cacau que usos otool para encontrar as bibliotecas compartilhadas necessárias que um aplicativo precisa para funcionar corretamente. Por exemplo, digamos que eu executar otool -L em um aplicativo que usa QTKit.framework. Posso obter uma lista das bibliotecas compartilhadas usadas pelo programa (incluindo os quadros básicos como Cocoa.framework e AppKit.framework):
/System/Library/Frameworks/QTKit.framework/Versions/A/QTKit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.0.0)
..... and so on for a bunch of other frameworks
que mostra que o aplicativo usa QTKit.framework. No entanto, se eu usar "otool -L" novamente no binário para QTKit.framework (/System/Library/Frameworks/QTKit.framework/Versions/A/QTKit) fico com esta:
/System/Library/Frameworks/QTKit.framework/Versions/A/QTKit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
/System/Library/PrivateFrameworks/CoreMedia.framework/Versions/A/CoreMedia (compatibility version 1.0.0, current version 1.0.0)
/System/Library/PrivateFrameworks/MediaToolbox.framework/Versions/A/MediaToolbox (compatibility version 1.0.0, current version 1.0.0)
/System/Library/PrivateFrameworks/VideoToolbox.framework/Versions/A/VideoToolbox (compatibility version 1.0.0, current version 1.0.0)
/System/Library/PrivateFrameworks/CoreMediaIOServices.framework/Versions/A/CoreMediaIOServices (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 751.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1038.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 1584.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.6.0)
/System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox (compatibility version 1.0.0, current version 435.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 44.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 550.0.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 38.0.0)
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.6.0)
Isso mostra uma carga mais estruturas que a saída otool original no binário aplicativo mostrou. Existe uma maneira de ter otool executada de forma recursiva, o que significa que agarra os quadros que as necessidades de aplicativos, então entra e pesquisas cada uma dessas estruturas para dependências?
Solução
Não, você vai ter que correr otool repetidamente, ou incorporar o seu código de análise ( aqui ). Não se esqueça sobre a manipulação de @executable_path
.
Aqui está em Python (sem @executable_path
, canonização, ou nomes-com-espaços suportados), uma vez que este era mais fácil do que tentar pseudocódigo depuração:
import subprocess
def otool(s):
o = subprocess.Popen(['/usr/bin/otool', '-L', s], stdout=subprocess.PIPE)
for l in o.stdout:
if l[0] == '\t':
yield l.split(' ', 1)[0][1:]
need = set(['/Applications/iTunes.app/Contents/MacOS/iTunes'])
done = set()
while need:
needed = set(need)
need = set()
for f in needed:
need.update(otool(f))
done.update(needed)
need.difference_update(done)
for f in sorted(done):
print f
Outras dicas
Aqui está a minha solução que eu uso para a saída de correção de macdeployqt
ao usar bibliotecas Homebrew-instalados. O que eu encontrei é que macdeployqt
faz um bom trabalho de colocar os dylibs na pasta Framework, mas não consegue corrigir os caminhos.
https://github.com/jveitchmichaelis/deeplabel/blob/master /fix_paths_mac.py
Eu modificado roteiro Nicholas' para ser um pouco mais útil - ele corrige para @executable_path
, @rpath
e @loader_path
. Este não é exatamente o código de produção, mas tem deixe-me rodar aplicativos em outros Macs sem dependências já instalados.
Executar com: python fix_paths_mac.py ./path/to/your.app/Contents/MacOS/your_exe
. ou seja, apontar para o binário dentro de um pacote de aplicativo e ele vai descobrir o resto.
Eu tenho assumido que a maioria dos problemas vêm de coisas ligadas a /usr/local
. Então, se o código detecta que há uma dependência que aponta para um arquivo em /usr/local
, que vai corrigir os caminhos adequadamente. Você pode alterar a instrução pass
para copiar em um arquivo se não é na pasta Frameworks
, mas eu não encontrei uma situação onde há uma dylib faltando, é só ligado errado.
import subprocess
import os
import sys
from shutil import copyfile
executable = sys.argv[1]
app_folder = os.path.join(*executable.split('/')[:-3])
content_folder = os.path.join(app_folder, "Contents")
framework_path = os.path.join(content_folder, "Frameworks")
print(executable)
print("Working in {} ".format(app_folder))
def file_in_folder(file, folder):
return os.path.exists(os.path.join(folder, file))
def otool(s):
o = subprocess.Popen(['/usr/bin/otool', '-L', s], stdout=subprocess.PIPE)
for l in o.stdout:
l = l.decode()
if l[0] == '\t':
path = l.split(' ', 1)[0][1:]
if "@executable_path" in path:
path = path.replace("@executable_path", "")
# fudge here to strip /../ from the start of the path.
path = os.path.join(content_folder, path[4:])
if "@loader_path" in path:
path = path.replace("@loader_path", framework_path)
if "@rpath" in path:
path = path.replace("@rpath", framework_path)
dependency_dylib_name = os.path.split(path)[-1]
if "usr/local" in path:
if app_folder in s:
print("Warning: {} depends on {}".format(s, path))
if file_in_folder(dependency_dylib_name, framework_path):
print("Dependent library {} is already in framework folder".format(dependency_dylib_name))
print("Running install name tool to fix {}.".format(s))
if dependency_dylib_name == os.path.split(s)[-1]:
_ = subprocess.Popen(['install_name_tool', '-id', os.path.join("@loader_path", dependency_dylib_name), s], stdout=subprocess.PIPE)
_ = subprocess.Popen(['install_name_tool', '-change', path, os.path.join("@loader_path", dependency_dylib_name), s], stdout=subprocess.PIPE)
else:
# Potentially you could copy in the offending dylib here.
pass
yield path
need = set([executable])
done = set()
while need:
needed = set(need)
need = set()
for f in needed:
need.update(otool(f))
done.update(needed)
need.difference_update(done)