Eu fiz a mesma jogada anos atrás. Aqui estão as coisas que eu encontrei:
Seu desktop médio Linux tem uma área de usuário mais rica que a do OS X.
Você provavelmente perderá ferramentas diferentes das que eu fiz, por isso não faz sentido ficar específico sobre as recomendações para substituições.
Em vez disso, basta instalar o Fink , MacPorts ou Homebrew . Esses sistemas fornecem um sistema de gerenciamento de pacotes típico do Linux ou dos BSDs. Cada um tem seu próprio sabor e conjunto de embalagens, portanto, a escolha certa será baseada em seus gostos e necessidades.
Você pode achar que nenhum sistema de pacote terá todos os programas que você precisa. Alguns programas ainda precisam ser portados para o OS X, para que não apareçam em nenhum sistema de pacotes. No entanto, esses sistemas estendem muito o que é fornecido com o OS X e facilitarão sua transição do Linux.
Os compiladores de linha de comando do OS X agora criam executáveis de 64 bits por padrão.
No Leopard e versões anteriores, os compiladores criavam executáveis de 32 bits por padrão. Isso pode causar problemas de várias maneiras: talvez você tenha bibliotecas antigas de 32 bits que não podem ser reconstruídas, mas precisa vincular, talvez ainda esteja executando o sistema no modo de 32 bits, etc.
Uma maneira de forçar uma compilação de 32 bits é substituir os gccpadrões nos sistemas de compilação gcc-4.0, sendo esse o antigo compilador Leopard de 32 bits por padrão. ( gccé um link simbólico para o padrão de 64 bits gcc-4.2no Snow Leopard.) Nos sistemas de construção baseados em autoconf, isso funciona:
$ ./configure CC=gcc-4.0 CXX=g++-4.0
(Você só precisa do CXXbit se o programa contiver componentes C ++.)
Outra maneira é passar -m32para o compilador e o vinculador:
$ ./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
É mais digitado, mas permite que você obtenha compilações de 32 bits do GCC mais recente.
A ligação dinâmica é muito diferente.
Se você é do tipo de escrever seus ldcomandos manualmente, é hora de quebrar esse hábito. Em vez disso, você deve vincular programas e bibliotecas através do compilador ou usar um intermediário libtool. Eles cuidam das diferenças de esquema de link específicas da plataforma, para que você possa economizar o poder do cérebro em programas de aprendizado que não pode abstrair com mecanismos portáteis.
Por exemplo, você precisará atualizar sua memória muscular para digitar em otool -L someprogramvez de ldd someprogramdescobrir a que bibliotecas someprogramestá vinculada.
Outra diferença no vínculo dinâmico que irá mudar seu cérebro a princípio é que, no OS X, o local de instalação de uma biblioteca é gravado na própria biblioteca e o vinculador o copia no executável no momento do link. Isso significa que, se você vincula uma biblioteca que foi instalada, /usr/local/libmas deseja enviá-la aos seus usuários no mesmo diretório que o executável, é necessário dizer algo como isso como parte do processo de instalação:
$ cp /usr/local/lib/libfoo.dylib .
$ install_name_tool -id @loader_path/libfoo.dylib libfoo.dylib
$ make LDFLAGS=-L. relink
Agora, é provável que grande parte do exposto varie para o seu sistema de compilação, então tome isso como um exemplo, e não como uma receita. O que isso faz é criar uma cópia privada de uma biblioteca à qual vinculamos, alterar seu identificador de biblioteca compartilhada de um caminho absoluto para um significado relativo "no mesmo diretório que o executável" e forçar a reconstrução do executável contra essa cópia modificada da biblioteca.
install_name_toolé o comando principal aqui. Se, em vez disso, você desejasse instalar a biblioteca em um ../libdiretório relativo ao executável, o -idargumento precisaria estar @loader_path/../lib/libfoo.dylib.
Joe Di Pol escreveu um bom artigo sobre isso , com muito mais detalhes.
Ligação dinâmica + pacotes de terceiros podem causar dores de cabeça desde o início.
É provável que você tenha problemas de ligação dinâmica desde o início, assim que começar a tentar usar bibliotecas de pacotes de terceiros que não instalam as bibliotecas em locais padrão. O MacPorts faz isso, por exemplo, instalando bibliotecas em /opt/local/libvez de /usr/libou em /usr/local/lib. Quando você se deparar com isso, uma boa solução para o problema é adicionar linhas como as seguintes .bash_profile:
# Tell the dynamic linker (dyld) where to find MacPorts package libs
export DYLD_LIBRARY_PATH=/opt/local/lib:$DYLD_LIBRARY_PATH
# Add MacPorts header file install dirs to your gcc and g++ include paths
export C_INCLUDE_PATH=/opt/local/include:$C_INCLUDE_PATH
export CPLUS_INCLUDE_PATH=/opt/local/include:$CPLUS_INCLUDE_PATH
O OS X lida com o problema de compatibilidade da CPU de maneira diferente do Linux.
Em um Linux de 64 bits em que você também precisa suportar 32 bits por qualquer motivo, você acaba com duas cópias de bibliotecas que precisam estar nos dois formatos, com as versões de 64 bits desativadas em um lib64diretório paralelo ao libdiretório tradicional .
O OS X resolve esse problema de maneira diferente, com o conceito binário Universal, que permite colocar vários binários em um único arquivo. Atualmente, você pode ter executáveis que suportam até 4 tipos de CPU: PowerPC de 32 e 64 bits, além de Intel de 32 e 64 bits.
É fácil criar binários universais com o Xcode, mas é um pouco trabalhoso com as ferramentas de linha de comando. Isso proporciona uma compilação universal da Intel, apenas com sistemas de compilação baseados no Autoconf:
$ ./configure --disable-dependency-tracking CFLAGS='-arch i386 -arch x86_64' \
LDFLAGS='-arch i386 -arch x86_64'
Adicione -arch ppc -arch ppc64ao CFLAGSe LDFLAGSse precisar de suporte do PowerPC.
Se você não desabilitar o rastreamento de dependências, acaba criando apenas para uma plataforma, pois a presença de .oarquivos recém-criados para a primeira plataforma convence make(1)que não é necessário criar também para a segunda plataforma. Tudo deve ser construído duas vezes no exemplo acima; quatro vezes para um binário totalmente universal, se você ainda precisar do suporte ao PowerPC.
(Mais informações na Nota técnica da Apple TN2137 .)
As ferramentas do desenvolvedor não estão instaladas no OS X por padrão.
Antes do Lion, o local mais confiável para obter as ferramentas de desenvolvimento corretas para o seu sistema era nos discos do sistema operacional. Eles são uma instalação opcional.
O bom de instalar as ferramentas de desenvolvimento a partir dos discos do SO é que você sabe que as ferramentas funcionarão com o SO. Como a Apple é Apple, você precisa ter uma versão recente do sistema operacional para executar os compiladores mais recentes, e eles nem sempre disponibilizam downloads de ferramentas antigas; portanto, os discos do sistema operacional costumam ser a maneira mais fácil de encontrar as ferramentas certas para um determinado dev ou caixa de teste.
Com o Lion, eles estão tentando acabar com a instalação de mídia. Portanto, a menos que você compre a versão cara da chave USB, precisará fazer o download do Xcode na App Store .
Eu recomendo que você mantenha pelo menos algumas versões de quaisquer DMGs do Xcode que você baixar. Quando o sucessor do Lion for lançado daqui a um ou três anos, você poderá encontrar uma maneira de instalar uma versão contemporânea do Xcode em uma VM de teste do Lion. Planeje com antecedência, caso os problemas de disponibilidade e a falta de mídia do SO tornem impossíveis as versões antigas do Xcode.