it-swarm-es.tech

Desarrollador de software que cambia de Linux a OS X, ¿cuáles son las trampas?

He usado Ubuntu/Fedora/Red Hat/Suse pero no he usado OS X en absoluto. Si tengo que comenzar a usar OS X regularmente, ¿cuáles son las cosas que debo tener en cuenta?

Las herramientas que uso son GNU cadena de herramientas, C++/Boost, etc.

51
grokus

Hice el mismo movimiento hace años. Estas son 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, simplemente 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 descubrir 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 el sistema de paquetes any. 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 gcc por defecto en los sistemas de compilación con gcc-4.0, Que es el antiguo compilador Leopard de 32 bits por defecto. (gcc es un enlace simbólico a 64 bits por defecto gcc-4.2 en 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 bit CXX si el programa contiene componentes C++).

    Otra forma es pasar -m32 Al 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.

  • El enlace dinámico es muy diferente.

    Si eres del tipo que escribe tus comandos ld 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 programas de aprendizaje que no puede abstraer con mecanismos portátiles.

    Por ejemplo, necesitará actualizar su memoria muscular para que escriba otool -L someprogram En lugar de ldd someprogram Para averiguar a qué bibliotecas someprogram está 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 enlace hora. Esto significa que si se vincula a una biblioteca que se instaló en /usr/local/lib Pero 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 vinculamos, 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_tool Es el comando principal aquí. Si, en cambio, desea instalar la biblioteca en un directorio ../lib Relativo al ejecutable, el argumento -id Debería ser @loader_path/../lib/libfoo.dylib.

    Joe Di Pol escribió n 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/lib, En lugar de /usr/lib O /usr/local/lib. Cuando se encuentre con esto, una buena solución para el problema es agregar líneas como las siguientes a su .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 apagadas en un lib64 directorio paralelo al directorio tradicional lib.

    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 ppc64 A CFLAGS y LDFLAGS si necesita soporte para PowerPC.

    Si no deshabilita el seguimiento de dependencias, terminará compilando solo para una plataforma, ya que la presencia de archivos .o Recién construidos para la primera plataforma convence a make(1) de que no necesita para construir para la segunda plataforma, también. 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 Nota técnica de Apple TN2137 .)

  • Las herramientas de desarrollador no están instaladas en OS X por defecto.

    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 los más fáciles manera de encontrar las herramientas correctas para un determinado desarrollador o cuadro de 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.

53
Warren Young

ENORME GOTCHA: el sistema de archivos de Mac OS NO distingue entre mayúsculas y minúsculas.

30
gabe.

Aunque Fink y MacPorts son los medios tradicionales para obtener paquetes de Unix en OS X, recomiendo que compruebes una herramienta más nueva llamada brew que me ha funcionado mejor y ha tenido menos problemas con mi sistema, y ​​es mucho más fácil de usar. utilizar. Básicamente solo descarga tarballs e instala a/usr/local, pero automatiza todo el proceso muy bien.

http://mxcl.github.com/homebrew/

9
Sandy

ENORME GOTCHA: el sistema de archivos de Mac OS NO distingue entre mayúsculas y minúsculas.

Puede crear una imagen de disco sensible a mayúsculas y minúsculas en Mac OS X que se puede montar como un volumen de disco duro normal.

# cf. http://codesnippets.joyent.com/posts/show/8617
IMAGE="${HOME}/Desktop/Case Sensitive Test.dmg"
VOLNAME="Case Sensitive Test"

hdiutil create "${IMAGE}" -size 10m -fs HFSX -volname "${VOLNAME}" -layout NONE

hdiutil attach "${IMAGE}"

cd "/Volumes/${VOLNAME}"
touch foo.txt Foo.txt
open .
ls -l [Ff]oo.txt
stat -f "inode: %i  --  name: %N" [Ff]oo.txt

cd ~
hdiutil detach "/Volumes/${VOLNAME}"
4
taco

Al portar una pila de red de Solaris, BSD, Linux y Windows a OSX, el único punto principal que llama la atención es que, al igual que FreeBSD, toda la cadena de herramientas es bastante antigua.

Apple está acelerando con OSX Lion pero Leopard, Snow Leopard está bastante por detrás de las distribuciones modernas de Linux y muchos estándares no son compatibles. En mi caso, la falta de RFC 3678 (Extensiones de interfaz de socket para filtros de origen de multidifusión) es bastante inconveniente.

En el servidor OSX, instalé un sistema de archivos que distingue entre mayúsculas y minúsculas, ya que recomienda hacerlo para el servicio HTTP.

  • Antiguo GCC
  • Old Autoconf, Automake, libtool
  • Sin spinlocks de Pthread, OSX ofrece alternativas nativas.
  • No hay muchas API NSS re-rentrant.
  • No es demasiado útil /proc sistema de archivos.
  • No /dev/rtc, /dev/hpet, y RDTSC parece estar entorpecido. OSX ofrece alternativas nativas.
  • No epoll, pero tienes poll y kqueue
3
Steve-o

Aquí hay una buena fuente de artículos de desarrollo seleccionados, la Lista de literatura de cacao:

http://osx.hyperjeff.net/Reference/CocoaArticles

(Esto puede ser especialmente útil si algún día desea utilizar las ventajas específicas de Mac OS X).

3
frank

OS X admite pthread_cond_timedwait pero usa el tiempo calendario absoluto y no hay forma de usar un tiempo monotónicamente creciente.

1
andrewrk