Hice el mismo movimiento hace años. Aquí están las cosas con las que me he encontrado:
Su escritorio promedio Linux tiene una tierra de usuario más rica que la de OS X.
Probablemente extrañará diferentes herramientas que yo, así que no tiene sentido ser específico acerca de las recomendaciones para los reemplazos.
En su lugar, solo instale Fink , MacPorts o Homebrew lo primero. Estos sistemas proporcionan un sistema de gestión de paquetes típico de Linux o los BSD. Cada uno tiene su propio sabor y conjunto de paquetes, por lo que la elección correcta se basará en sus gustos y necesidades.
Puede encontrar que ningún sistema de paquetes tendrá todos los programas que necesita. Algunos programas aún no se han portado a OS X, por lo que no aparecerán en ningún sistema de paquetes. Sin embargo, estos sistemas amplían en gran medida lo que se incluye con OS X y facilitarán su transición de Linux.
Los compiladores de línea de comandos de OS X ahora crean ejecutables de 64 bits por defecto.
En Leopard y versiones anteriores, los compiladores construyeron ejecutables de 32 bits de forma predeterminada. Esto puede causar problemas de varias maneras: tal vez tenga bibliotecas antiguas de 32 bits que no pueda reconstruir pero tenga que vincular, tal vez todavía esté ejecutando su sistema en modo de 32 bits, etc.
Una forma de forzar una compilación de 32 bits es anular los gccvalores predeterminados en los sistemas de compilación gcc-4.0, que es el antiguo compilador Leopard de 32 bits por defecto. ( gcces un enlace simbólico a los 64 bits por defecto gcc-4.2en Snow Leopard). Con los sistemas de compilación basados en autoconf, esto funciona:
$ ./configure CC=gcc-4.0 CXX=g++-4.0
(Solo necesita el CXXbit si el programa contiene componentes de C ++).
Otra forma es pasar -m32al compilador y al enlazador:
$ ./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32
Es más mecanografía, pero le permite obtener compilaciones de 32 bits del nuevo GCC.
La vinculación dinámica es muy diferente.
Si eres del tipo que escribe tus ldcomandos a mano, es hora de romper ese hábito. En su lugar, debería vincular programas y bibliotecas a través del compilador, o utilizar un intermediario como libtool. Estos se ocupan de las diferencias de esquemas de enlaces específicos de la plataforma, para que pueda ahorrar el poder del cerebro para los programas de aprendizaje que no puede abstraer con mecanismos portátiles.
Por ejemplo, necesitará actualizar su memoria muscular para escribir en otool -L someprogramlugar de ldd someprogramaveriguar a qué bibliotecas someprogramestá vinculada.
Otra diferencia en el enlace dinámico que al principio torcerá tu cerebro es que en OS X, la ubicación de instalación de una biblioteca se registra en la biblioteca misma , y el enlazador copia eso en el ejecutable en el momento del enlace. Esto significa que si vincula a una biblioteca que se instaló /usr/local/libpero desea enviarla a sus usuarios en el mismo directorio que el ejecutable, debe decir algo como esto como parte de su proceso de instalación:
$ cp /usr/local/lib/libfoo.dylib .
$ install_name_tool -id @loader_path/libfoo.dylib libfoo.dylib
$ make LDFLAGS=-L. relink
Ahora, es probable que gran parte de lo anterior varíe para su sistema de compilación, así que solo tómelo como un ejemplo, en lugar de una receta. Lo que esto hace es hacer una copia privada de una biblioteca a la que enlazamos, cambia su identificador de biblioteca compartida de una ruta absoluta a una relativa que significa "en el mismo directorio que el ejecutable", luego obliga a reconstruir el ejecutable contra esta copia modificada de la biblioteca
install_name_tooles el comando central aquí. Si, en cambio, desea instalar la biblioteca en un ../libdirectorio relativo al ejecutable, el -idargumento debería ser @loader_path/../lib/libfoo.dyliben su lugar.
Joe Di Pol escribió un buen artículo sobre esto , con muchos más detalles.
El enlace dinámico + los paquetes de terceros pueden causar dolores de cabeza desde el principio.
Es probable que se encuentre con problemas de vinculación dinámica desde el principio, tan pronto como comience a intentar usar bibliotecas de paquetes de terceros que no instalen las bibliotecas en ubicaciones estándar. MacPorts hace esto, por ejemplo, instalando bibliotecas en /opt/local/liblugar de /usr/libo /usr/local/lib. Cuando te encuentres con esto, una buena solución para el problema es agregar líneas como las siguientes a tu .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
OS X maneja el problema de compatibilidad de la CPU de manera diferente a Linux.
En un Linux de 64 bits donde también debe admitir 32 bits por cualquier razón, termina con dos copias de cosas como bibliotecas que deben estar en ambos formatos, con las versiones de 64 bits desactivadas en un lib64directorio paralelo al libdirectorio tradicional
OS X resuelve este problema de manera diferente, con el concepto binario Universal, que le permite poner múltiples archivos binarios en un solo archivo. Actualmente puede tener ejecutables que admitan hasta 4 tipos de CPU: PowerPC de 32 y 64 bits, más Intel de 32 y 64 bits.
Es fácil construir binarios universales con Xcode, pero un poco complicado con las herramientas de línea de comandos. Esto le proporciona una compilación universal solo para Intel con sistemas de compilación basados en Autoconf:
$ ./configure --disable-dependency-tracking CFLAGS='-arch i386 -arch x86_64' \
LDFLAGS='-arch i386 -arch x86_64'
Agregue -arch ppc -arch ppc64al CFLAGSy LDFLAGSsi necesita soporte de PowerPC.
Si no deshabilita el seguimiento de dependencias, termina compilando solo para una plataforma, ya que la presencia de .oarchivos recién creados para la primera plataforma convence de make(1)que no es necesario construir también para la segunda plataforma. Todo tiene que ser construido dos veces en el ejemplo anterior; cuatro veces para un binario completamente universal, si aún necesita soporte de PowerPC.
(Más información en la Nota técnica de Apple TN2137 .)
Las herramientas de desarrollador no están instaladas en OS X de forma predeterminada.
Antes de Lion, el lugar más confiable para obtener las herramientas de desarrollo adecuadas para su sistema era en los discos del sistema operativo. Son una instalación opcional.
Lo bueno de instalar las herramientas de desarrollo desde los discos del sistema operativo es que sabe que las herramientas funcionarán con el sistema operativo. Apple, siendo Apple, debe tener una versión reciente del sistema operativo para ejecutar los últimos compiladores, y no siempre han hecho descargas de herramientas antiguas disponibles, por lo que los discos del sistema operativo son a menudo la forma más fácil de encontrar las herramientas adecuadas para un determinado caja de desarrollo o prueba.
Con Lion, intentan eliminar los medios de instalación, por lo que, a menos que compre la costosa versión de la llave USB, tendrá que descargar Xcode de la App Store .
Le recomiendo que mantenga al menos algunas versiones de cualquier DMG de Xcode que descargue. Cuando el sucesor de Lion salga dentro de un año o tres, es posible que se encuentre sin una forma de instalar una versión contemporánea de Xcode en una máquina virtual de prueba de Lion. Planifique con anticipación en caso de que los problemas de disponibilidad y la falta de medios del sistema operativo hagan que las versiones antiguas de Xcode de otra manera no se puedan obtener.