Como distribuir um Mac OS X com bibliotecas dependentes?

Question

Eu tenho um programa (especificamente minha entrada para a SO DevDays contagem regressiva desafio aplicativo ) que se baseia em várias bibliotecas dinâmicas, ou seja, libSDL, libSDL_ttf, e outros. Eu tenho essas bibliotecas instaladas sob /opt/local/lib via MacPorts, e muitas pessoas não têm estes instalados (e alguns podem tê-los instalados, mas não naquele local).

Como posso distribuir meu programa para que as pessoas sem essas bibliotecas instaladas pode executá-lo out-of-the-box? Obviamente, eu vou ter que distribuir os vários arquivos .dylib, mas fazer isso é insuficiente. O carregador dinâmico ainda olha para as bibliotecas instaladas nos locais que eu tê-los instalados no. Existe uma maneira de dizer o carregador dinâmico para procurar no diretório atual do executável, como o que o Windows faz com DLLs? As pessoas não deveriam ter de modificar as variáveis ??de ambiente (por exemplo DYLD_LIBRARY_PATH), uma vez que outra vez eu quero que isso funcione out-of-the-box.

Answer 1

Como você mencionou você não está usando o Xcode, por isso é um pouco difícil. Aqui estão opções na minha ordem de preferência:

1. Mudar para Xcode. Use frameworks. As bibliotecas SDL estão disponíveis como estruturas já, e eu vi mais do que um par de jogos comerciais com um libsdl.framework dentro do pacote do aplicativo.

2. Use frameworks, mas mantenha seu Makefiles. Faça o download das versões de enquadramento de suas bibliotecas SDL (ou construí-los você mesmo), e da ligação com eles com a bandeira -framework vinculador. Distribuir os quadros com a sua aplicação ou não fazer, e dizer a seus usuários para colocá-los em qualquer ~ / Library / Frameworks ou em / Library / Frameworks. Eu não me preocupei com um instalador para isso.

3. link estaticamente contra SDL. No Makefile, você terá que listar o caminho das bibliotecas estáticas em vez de usar o sinalizador -l, por exemplo, você executar "blah /opt/local/lib/libsdl.a ld blah". Não há nenhuma maneira que eu sei para contar -l preferir estáticos bibliotecas mais comuns, e acreditem, eu olhei.

Answer 2

A abordagem básica para isso é enviá-los no pacote .app. Em seguida, você modificar o local dos olhares vinculador para bibliotecas compartilhadas para incluir isso.

Os passos são:

1. Criar um novo copiar arquivos fase de construção para o seu alvo que as cópias desses arquivos no diretório Frameworks do pacote .app.

2. Editar a configuração construir "RUNPATH caminhos de busca" para incluir @executable_path/../Frameworks

Se você construir seu executável com essas mudanças e, em seguida, olha, você deve achar que existem as dylibs no diretório Foo.app/Contents/Framework e funcionando otool -L Foo.app/Contents/MacOS/Foo deve render ea entrada prefixados por @rpath para aqueles dylibs.

A partir deste Cocoabuilder pós :

Em geral, @loader_path é preferido sobre @executable_path, como
permite estruturas para trabalho embutido em ambos um executável e um pacote,
plugin, ou sub-quadro. A única desvantagem é que @loader_path
requer 10.4 ou mais recente. Se você estiver em 10.5 ou mais recente, @rpath é ainda
melhor do que @loader_path.

Answer 3

estaticamente vincular as bibliotecas.