Ho un file di libreria statico chiamato libunp.a, so che potrei usare gcc -lunp xx per collegarmi alla libreria.#pragma comment (lib, "xxx.lib") equivalente in Linux?
Potrei usare #pragma comment(lib,"xxx.lib") per indicare al compilatore Microsoft C/C++ di includere la libreria; come potrei farlo sotto Linux/GCC?
Semplice; non puoi GCC non ha questo equivalente. Specificare -l come parametro gcc, creare uno script linker, chiamare ld, chiamare il 911 o qualsiasi altra cosa.
Non che un tale pragma abbia senso. Le librerie dovrebbero essere specificate durante la fase di collegamento. Tali informazioni semplicemente non appartengono all'interno di un'unità di traduzione. Un'unità di traduzione può essere preelaborata, compilata e assemblata anche senza una fase di collegamento. La toolchain utilizzata da Visual Studio lo consente perché è Braindead e sempre esegue il collegamento.
Si potrebbe desiderare di risparmiare un po 'di battitura noioso e creare un makefile per il progetto: GNU Make Manual
Non sembra esserci alcuna menzione di eventuali direttive equivalenti nello GCC manual's page on pragmas.
Una ragione per cui GCC non supportava il collegamento nel codice sorgente era che a volte, correct linking depends on link order; e questo richiederebbe che l'ordine di collegamento avvenga correttamente, indipendentemente dall'ordine di compilazione. Se hai intenzione di dedicarti a tanto lavoro, potresti anche passare gli argomenti del linker sulla riga di comando (o in altro modo), suppongo.
Lo stesso vale per alcuni, se non tutti i compilatori di Windows. Ma sì, tali direttive sono __bad__ –
"la corretta compilazione dipende dall'ordine del collegamento." - No, come afferma l'articolo collegato, il corretto LINKING dipende dall'ordine del link. –
biblioteche dovrebbero essere specificati durante la fase di collegamento. Tali informazioni semplicemente non appartengono all'interno di un'unità di traduzione. Un'unità di traduzione può essere preelaborata, compilata e assemblata anche senza una fase di collegamento.
Semplicemente perché #pragma comment(lib,"xxx.lib") è nel file di origine, non significa che il compilatore lo consuma. Infatti, entra come commento e viene successivamente utilizzato dal linker. Non molto diverso da * nix.
Non hai completamente ragione, ci sono alcuni casi come usare ROOT (root.cern.ch) dove questo potrebbe essere molto utile. – RSFalcon7
Negli ultimi decenni è diventato popolare per i programmatori progettare i file .h e .lib per avere un qualche tipo di relazione tra loro. In tal caso, ha senso che un file .h contenga un pragma che dice al linker di collegare il file .lib corrispondente. Sicuro gcc non ce l'ha, ma questo non significa che non ha senso. –
Quindi si assume che le librerie non richiedano percorsi aggiuntivi né flag durante il collegamento. Questo è principalmente vero su Windows, quindi perché la pragma "funziona" nell'ambiente di Visual Studio. Le altre direttive di gcc sono almeno coerenti tra i diversi tipi di Linux/Solaris/BSD, purché si utilizzi la stessa versione di gcc. I percorsi sono comunque, no. Questo è il motivo per cui ha perfettamente senso separare la fase di costruzione negli script di configurazione o nei makefile. Non ha nulla a che fare con le unità di traduzione. Prova a portare il software a volte ;-) –
@Mads: Il fatto che Unix sia una piattaforma fratturata che richiede la separazione delle fasi di generazione e collegamento e tutto il dolore che ne consegue, non è una giustificazione per cestinare il modo in cui Windows lo fa, che è molto più facile da gestire e consente agli implementatori di librerie di eliminare quel dolore dai loro utenti. L'idea che l'approccio Unix sia più difficile ma migliore è il puro masochismo irrazionale. –