2015-05-10 7 views
7

Ho compilato SFML usando CMake per MinGW. Dopo aver eseguito "mingw32-make install", tutto è compilato e installato senza errori. Ma quando si eseguono gli esempi - pong.exe, sound.exe, sound-capture.exe e voip.exe dipendono tutti da openal32.dll.SFML non sta collegando staticamente a openal32 (link staticamente a tutte le altre dipendenze)

Ho specificato SFML_USE_STATIC_LIBS = true durante la configurazione di CMake e tutte le altre dipendenze dell'eseguibile di esempio sono solo su dll nativi di Windows.

Qualcuno può spiegare perché ha collegato dinamicamente a openal32 (ma nient'altro)?

Modifica: Mi sono appena imbattuto in questa discussione http://en.sfml-dev.org/forums/index.php?topic=262.0 che sta discutendo esattamente lo stesso problema. Avrei pensato (dal momento che questo è del 2008) che questo sarebbe stato implementato ormai. O è ancora nella stessa situazione?

Modifica 2: Le risposte qui http://en.sfml-dev.org/forums/index.php?topic=18119.0 indicano che OpenAL deve essere collegato dinamicamente a causa della licenza. Qualcuno può confermare se la licenza consente o meno la distribuzione di openal32.dll con l'eseguibile?

risposta

3

Non sono un avvocato (e non sono stato in una famosa catena alberghiera ieri sera).

OpenAL implementation they are using è concesso in licenza con lo GNU Library General Public License (LGPL), version 2. LGPL v2 richiede che:

Se si collega un programma con la libreria, è necessario fornire i file oggetto completi ai destinatari in modo che essi possano ricollegarli con la libreria, dopo aver apportato modifiche alla libreria e ricompilata. E tu devi mostrare loro questi termini in modo che conoscano i loro diritti.

Il modo più semplice per consentire agli utenti di ricollegare un gioco closed-source con una libreria modificata OpenAL, è quello di rendere quel collegamento gioco dinamicamente con il openal32.dll. In questo modo, possono semplicemente sostituire lo openal32.dll con uno modificato e posizionarlo accanto al file eseguibile del gioco.

Per quanto riguarda questa parte della patente:

E deve mostrar loro queste condizioni in modo che conoscano i loro diritti.

Basta informare gli utenti che il gioco utilizza OpenAL e in qualche modo accedere al corpo del testo v2 LGPL.

puoi distribuire l'openal32.dll con il gioco, in queste condizioni:

Per esempio, chi distribuisce copie della libreria, sia gratis o per una tassa, è necessario dare ai destinatari tutti i diritti che abbiamo dato a te . È necessario assicurarsi che anche loro ricevano o possano ottenere il codice sorgente .

Ciò può essere soddisfatto semplicemente informando gli utenti che il gioco utilizza OpenAL e fornendo un collegamento a cui è possibile scaricare il codice sorgente.

Per informare gli utenti dei loro diritti relativi a OpenAL, è possibile farlo in una pagina "Informazioni" all'interno del gioco stesso o in una prefazione/appendice del manuale di gioco distribuito. Per esempio:

questo gioco utilizza il seguente software open-source:

E mentre si sta informando gli utenti di OpenAL, si potrebbe si offre inoltre volontario per dare l'attribuzione ad altre librerie open-source utilizzate dal gioco, come SFML.

+0

Eccellente, grazie! Sono arrivato a conclusioni simili sui termini LGPL ma la tua risposta mi ha chiarito le cose immensamente. – Kvothe

+0

Significa che se si dovesse collegare staticamente a una libreria con licenza LGPL, si dovrebbero rendere disponibili i file oggetto generati dal codice sorgente (ma non il codice sorgente stesso) in modo che l'utente possa ricollegarli insieme a un versione diversa della libreria statica? – Kvothe

+1

Lo dice direttamente nella licenza LGPL stessa: _Se colleghi un programma alla libreria, devi fornire i file oggetto completi ai destinatari in modo che possano ricollegarli con la libreria, dopo aver apportato modifiche alla libreria e ricompilandola._ –