Oggetti condivisi portatili?

Question

È possibile utilizzare file di oggetti condivisi in modo portatile come DLL in Windows ??

Mi chiedo se esiste un modo per fornire una libreria compilata, pronta per l'uso, per Linux. Allo stesso modo è possibile compilare una DLL in Windows e può essere utilizzata su qualsiasi altro Windows (ok, non QUALUNQUE altro, ma sulla maggior parte di essi può).

È possibile in Linux?

Modifica
Mi sono appena svegliato e ho letto le risposte. Ce ne sono di ottimi.
Non sto cercando di nascondere il codice sorgente. Voglio solo fornire una libreria già compilata e pronta per l'uso, quindi gli utenti senza esperienza sulla compilazione non devono farlo da soli.
Quindi l'idea è quella di fornire un file .so che funzioni su quanti più Linux possibili.
La libreria è scritta in C ++, usando le librerie STL e Boost.

Answer 1

Consiglio altamente altamente di utilizzare l'app di controllo librerie / app LSB. Ti dirà rapidamente se:

• Stanno usando estensioni non disponibili in alcune distro
• Introduci bash-isms negli script di installazione
• Usa i syscall che non sono disponibili in tutti i kernel recenti
• Dipende da librerie non standard (ti dirà quali distro le mancano)
• E molti, su molti altri ottimi controlli

Puoi ottenere maggiori informazioni qui e scaricare lo strumento. È facile da eseguire .. basta decomprimerlo, eseguire uno script perl e puntare il browser su localhost .. il resto è guidato dal browser.

Usando lo strumento, puoi ottenere facilmente la tua libreria / app LSB certificata (per entrambe le versioni) e rendere il lavoro del pack pack distro molto più semplice.

Oltre a ciò, usa semplicemente qualcosa come libtool (o simile) per assicurarti che la tua libreria sia installata correttamente, fornisci un oggetto statico per le persone che non vogliono collegarsi al DSO (ci vorrà del tempo prima che la tua libreria appaia nella maggior parte delle distribuzioni, quindi scrivendo un programma portatile, non posso contare sul fatto che sia presente) e commentare bene la tua interfaccia pubblica.

Per le biblioteche, trovo che Doxygen funziona al meglio. La documentazione è molto importante, influenza sicuramente la mia scelta della biblioteca da utilizzare per un determinato compito.

Davvero, ancora una volta, controlla il checker dell'app, ti fornirà rapporti sui problemi di portabilità che richiederebbero un anno per avere la libreria in libertà per ottenere altrimenti.

Infine, prova a rendere la tua libreria facile da inserire "nella struttura", quindi non devo collegarmi staticamente. Come ho detto, potrebbero essere necessari un paio d'anni prima che diventi comune nella maggior parte delle distribuzioni. È molto più facile per me semplicemente prendere il tuo codice, rilasciarlo in src / lib e usarlo, fino a quando la tua libreria è comune. E per favore, per favore .. dammi dei test unitari, TAP (prova qualsiasi protocollo) è un modo buono e portatile per farlo. Se hackero la tua libreria, devo sapere (rapidamente) se l'ho rotta, specialmente quando la modifico in tree o en situ (se esiste il DSO).

Answer 2

Se desideri aiutare i tuoi utenti fornendo loro il codice compilato, il modo migliore che conosco è quello di fornire loro una documentazione + binaria collegata staticamente su come possono eseguire il binario. (Ciò è probabilmente in aggiunta a fornire loro il codice sorgente.) La maggior parte dei binari collegati staticamente funzionano sulla maggior parte delle distribuzioni Linux della stessa architettura (+ 32 bit (x86) binari collegati staticamente funzionano su 64 bit (amd64)). Non c'è da meravigliarsi che Skype fornisca un download Linux collegato staticamente.

Torna alla domanda sulla tua biblioteca. Anche se sei un esperto nello scrivere librerie condivise su Linux e ti prendi il tuo tempo per ridurre al minimo le dipendenze in modo che la tua libreria condivisa funzioni su diverse distribuzioni Linux, incluse vecchie e nuove versioni, non c'è modo di assicurarti che funzioni in futuro (diciamo, 2 anni). Molto probabilmente finirai per mantenere il file .so, cioè apportando piccole modifiche ripetutamente in modo che il file .so diventi compatibile con le nuove versioni delle distribuzioni Linux. Non è divertente da molto tempo e riduce sostanzialmente la produttività: il tempo speso per mantenere la compatibilità della biblioteca sarebbe stato molto meglio speso ad es. migliorare la funzionalità, l'efficienza, la sicurezza ecc. del software.

Si noti inoltre che è molto facile sconvolgere gli utenti fornendo una libreria in formato .so, che non funziona sul loro sistema. (E non hai la superpotenza per farlo funzionare su tutti sistemi Linux, quindi questa situazione è inevitabile.) Fornisci anche 32 bit e 64 bit, inclusi x86, PowerPC, BRACCIO ecc.? Se il file .so funziona solo su Debian, Ubuntu e Red Hat (perché non hai tempo per trasferire il file su più distribuzioni), molto probabilmente sconvolgerai i tuoi utenti SUSE e Gentoo (e altro).

Answer 3

Idealmente, ti consigliamo di utilizzare GNU autoconf , automake e libtool per creare gli script di configurazione e creazione, quindi distribuire la libreria come sorgente con i file configure e Makefile.in generati.

Ecco un libro online su di loro.

./ configure; rendere; make install è abbastanza standard in Linux.

La radice del problema è che Linux funziona su molti processori diversi. Non puoi semplicemente fare affidamento sul processore che supporta le istruzioni x86 come fa Windows (per la maggior parte delle versioni: Itanium (XP e più recenti) e Alpha (NT 4.0) sono le eccezioni).

Answer 4

Quindi, la domanda è: come sviluppare librerie condivise per Linux? Puoi dare un'occhiata a questo tutorial o the Pogram Library Howto .

Answer 5

So cosa stai chiedendo. Per Windows, MSFT ha accuratamente reso tutte le DLL compatibili, quindi le tue DLL sono generalmente compatibili per quasi tutte le versioni di Windows, ecco perché la chiami " portatile "

Sfortunatamente, su Linux ci sono troppe varianti (e tutti pensano di essere "diversi" per fare soldi) in modo da non poter ottenere gli stessi vantaggi di Windows, ed è per questo che abbiamo molti pacchetti compilati per distribuzioni diverse , versione distro, tipo di CPU, ...

Alcuni sostengono che il problema sia causato dall'architettura (CPU), ma non lo è. Anche sullo stesso arco, c'è ancora differenza tra le distribuzioni. Una volta che hai davvero provato a rilasciare un pacchetto binario, sapresti quanto sia difficile - anche la dipendenza della libreria runtime C è difficile da mantenere. Nel sistema operativo Linux mancano troppe cose, quindi quasi tutti i servizi comportano problemi di dipendenza.

Di solito è possibile creare solo binari compatibili con alcune distribuzioni (o diverse distribuzioni se si è fortunati). Questo è il motivo per cui il rilascio di programmi Linux in binario ha sempre rovinato, a meno che non sia legato a qualche distro come Ubuntu, Debian o RH.

Answer 6

Basta inserire un file .so in / usr / lib può funzionare, ma è probabile che tu abbia confuso lo schema che la tua distribuzione ha per la gestione delle librerie.

Dai un'occhiata alla base standard di Linux - Questa è la cosa più vicina a una piattaforma comune tra le distribuzioni di Linux.

http://www.linuxfoundation.org/collaborate/workgroups/lsb

Cosa stai cercando di realizzare?

Answer 7

La risposta di Tinkertim è perfetta. Aggiungerò che è importante comprendere e pianificare le modifiche a ABI di gcc . Le cose sono state abbastanza stabili di recente e immagino che tutte le maggiori distribuzioni siano su gcc 4.3.2 o giù di lì. Tuttavia, ogni pochi anni alcuni cambiano in ABI (specialmente i bit relativi a C ++) per provocare caos, almeno per coloro che vogliono rilasciare binari cross-distro e per gli utenti che si sono abituati a ritirare i pacchetti da altre distribuzioni rispetto a quelle effettivamente in esecuzione e trovando che funzionano. Mentre una di queste transizioni è in corso (tutte le distribuzioni si aggiornano al loro ritmo), idealmente vuoi rilasciare librerie con ABI che supportano l'intera gamma di versioni di gcc in uso dai tuoi utenti.