Quali sono i limiti dell'utilizzo di OS X quando si tratta di compilare ed eseguire strumenti e script basati su CLI che sono stati scritti pensando a Linux?

0

Di tanto in tanto eseguo piccoli script scientifici e strumenti C su OS X. Per gli strumenti C, ho appena scaricato l'origine e compilato utilizzando il Makefile fornito. Di solito non ho alcun problema quando uso gli strumenti.

Tuttavia, sapendo che quegli strumenti sono stati scritti su Linux il più delle volte, mi chiedo se le differenze di architettura (Linux è basato su System V, OS X è basato su BSD) presenteranno problemi.

    
posta William 07.07.2014 - 20:49
fonte

3 risposte

1

La maggior parte delle volte dovresti essere abbastanza sicuro.

OS-X è basato su BSD che, come Linux, è una variante di Unix, anche se una delle versioni più diverse.

Ha tuttavia chiamate kernel e OS molto simili ed è considerato conforme a Posix, che è la cosa principale necessaria per il funzionamento multipiattaforma.

Il più grande problema che devi affrontare quando si tratta della variazione di Apple sulle cose è

  • CPU e amp; Architettura del processore.
  • Aggiunte fatte al kernel del sistema operativo ma non rese nuovamente disponibili.

Prendendo ciascuno di questi a turno:

CPU e amp; Architettura del processore

Tutte le macchine Apple prodotte dal 2007 hanno CPU basate su Intel, tuttavia le macchine Apple precedenti utilizzavano una varietà di tipi di CPU diversi, dal Motorola 68000 fino all'IBM PowerPC.

Alcuni progetti Linux hanno in essi un linguaggio di assemblaggio in-line, specialmente cose che sono progettate per interfacciarsi con il kernel ad un livello molto basso.

In un giorno moderno Apple con un Intel, questo non è davvero un problema, ma se stai cercando di compilare qualcosa con una CPU non Intel, avrai dei problemi.

Fortunatamente, a causa della filosofia di Linux e della natura open source, questo tipo di pratica è disapprovato e molto raramente visto in applicazioni e strumenti regolari.

Inoltre, dove è noto che un'applicazione ha parti specifiche della piattaforma, spesso c'è uno script ./configure da eseguire che "configura" i sorgenti per la piattaforma su cui è costruita, o c'è un modo per specificare quale sia la build obiettivo dovrebbe essere.

Aggiunte fatte al kernel del sistema operativo ma non rese nuovamente disponibili allo stato selvaggio

Apple è famosa per aver dato il meglio di sé e, anche se non sono uno sviluppatore Apple (quindi non posso dire al 100% ciò che è e non è aggiunto), conosco molti altri sviluppatori chi sono.

Seguendo i vari commenti e le cose che mi sono state dette da altri, ci sono una serie di funzionalità del sistema operativo che sono disponibili solo nella variante Apples del SO base di Linux, e in alcuni casi, gli sviluppatori sono incoraggiati a utilizzarle luogo delle chiamate regolari.

Questo, tuttavia, dovrebbe solo influenzare il porting delle applicazioni andando in modo opposto, in quanto la piattaforma target è legata all'essere apple e non facilmente portabile ad altre varianti.

Portare le app esterne non dovrebbe essere un grosso problema, a patto che l'applicazione utilizzi solo chiamate API standard basate su posix e non provi a fare qualcosa di speciale o intelligente, né fare ipotesi sull'ambiente in cui è in esecuzione .

L'area in cui è più probabile avere problemi, si trova nello spazio della GUI. Beacuse la GUI è così strettamente legata alla libreria di finestre, e la libreria di finestre è dove si trova la maggior parte delle estensioni di terze parti di Apple, quindi IMHO se qualsiasi tipo di applicazione ti presenterà un mucchio di problemi, sarà qui .

La maggior parte delle robe generiche di Linux sono progettate per essere eseguite sotto un server X generico, o usando un toolkit come Gnome o Kde, entrambi i quali (correggimi se ho torto qui) mi permetto di credere non disponibile su OS-X.

    
risposta data 07.07.2014 - 21:22
fonte
1

Invece di compilare da zero, hai studiato Homebrew MacPorts e Fink. Tutti questi strumenti unix di porta su OSX con il sollevamento pesante già fatto per te. forniscono inoltre guide di porting per consentire il porting delle proprie applicazioni.

Ciascuno di questi sistemi ha i propri aderenti, ma per essere onesti sono molto più numerosi, ognuno ha punti di forza e di debolezza e nessuno è perfetto.

link

link

link

Ci sono altri progetti simili ma non li ho ancora provati. Attualmente sto usando Macport ma tutti sembrano funzionare bene.

    
risposta data 07.07.2014 - 21:06
fonte
1

A volte ci sono dei fastidi minori nel porting di codice da Linux a OS X. Ad esempio, fino a Lion, OS X non fornisce una funzione 'getline ()', quindi sei stato costretto a fornirti il tuo. Poi, quando Apple l'ha aggiunto a Lion, dovevi avere una compilazione condizionale per includere il getline () cresciuto in casa quando costruisci su Snow Leopard, e lasciarlo fuori quando costruisci su versioni più recenti di OS X. Non è scienza missilistica, ma è sicuramente fastidioso. A prescindere da nit come quello, l'API UNIX fornita da OS X è piuttosto compatibile con Linux.

Il più grande mal di testa ora è che Apple è passata a Clang per i suoi compilatori. La maggior parte dei progetti Linux sono ancora costruiti con GNU GCC e un sacco di codice che verrà compilato con i compilatori GNU GCC non verrà compilato utilizzando i compilatori Clang. Ad esempio, le librerie Boost sembrano essere danneggiate e quindi aggiornate con ogni nuova versione di Clang o Boost. Potrebbe essere necessario installare una copia dei compilatori GNU GCC da MacPorts o Homebrew per ottenere materiale da compilare.

    
risposta data 07.07.2014 - 21:25
fonte

Leggi altre domande sui tag