linking dinamico in zOS

Question

devo creare una libreria collegata dinamicamente in zOS. Quali sono le opzioni da passare al compilatore.

Inoltre, come controllare se una libreria in zOS è collegato dinamicamente [dipende] su altre librerie. abbiamo ldd in Linux, che mostra questo legame. Abbiamo un 'ldd' equivalente in terra zOS?

Answer 1

non dire direttamente, ma presumo si intende un C / C ++ DLL. Si può fare le librerie condivise in altre lingue come pure (anche assembler), ma i passi sarebbe stato diverso.

In primo luogo, è necessario decidere cosa si vuole esportare. Molti degli esempi di IBM utilizzano la direttiva del compilatore EXPORTALL, ma essere consapevoli questo può portare a eseguibili molto lenti, a seconda del vostro stile di codifica. Se non lo fai EXPORTALL, avrete bisogno #pragma esportazione per qualsiasi cosa (codice o dati) che si desidera esportare. Non dimenticate che è possibile esportare i dati (variabili) così come le funzioni eseguibili ... a volte avrete bisogno di questo per condividere i dati con funzioni di DLL.

Quindi, è necessario impostare le opzioni di compilazione su sia client (chiamante) e DLL per utilizzare il collegamento DLL ... questa è l'opzione di compilazione -WC, DLL e se abilitato, genera logica in più nel vostro programma per caricare e gestire la DLL. E 'una buona idea includere anche #pragma csect per le funzioni esportate se pensi che potrai mai avere la necessità di aggiornare la DLL senza sostituirlo completamente.

Quando si collega la DLL, assicurarsi di specificare l'opzione -Wl, DLL (ci sono un sacco di modi ... questa parte è diverso se si collega in modalità batch - Ti sto assumendo sta costruendo in un file di make di qualche tipo). Il collegamento genererà la DLL reale, così come una "piattaforma laterale" che contiene affermazioni "Importa" per tutte le funzioni esportate. Avrete bisogno di questi per collegare uno dei programmi lato client che si prevede di chiamare la DLL. Ad esempio, se le importazioni sono in un file chiamato AAA.x, C89 -WC, DLL myapp.c AAA.x sarebbe compilare il codice chiamante, con la consapevolezza che le funzioni in AAA.x sono fuori in una sorta di DLL.

Per il vostro punto circa DLL chiamata altre DLL, non dimenticate che una DLL può sia "servire" e "consumare" le funzioni ... includendo la piattaforma laterale per le funzioni in altre DLL, si può avere una DLL che fornisce alcune funzioni mentre denominano altre DLL di accesso gli altri.

L'attuale DLL stessa può essere in più luoghi a seconda della natura della vostra applicazione. Se stai servizi UNIX amichevole, è solo un eseguibile in LIBPATH. Può anche essere STEPLIB, LNKLST, LPA e così via.

Se è necessario, è possibile accedere ai DLL in modo esplicito in fase di esecuzione utilizzando dlopen (), dlsym () e così via. In generale, questo consente di controllare esattamente quali DLL che si sta utilizzando (a volte utile se l'utente in grado di fornire un se stesso), e ti dà ciò che equivale a puntatori a funzione che si risolvono all'interno della DLL.

Ci sono alcune altre cose fondamentali da considerare durante il collegamento, come assicurare che il codice è rientrante. La maggior parte di questi sono specificati nella documentazione di IBM, e se si costruisce con le cose come "C89" (o equivalente), le opzioni corrette sono di solito di installazione in modo automatico (in realtà, per ottenere una buona idea di quello che sta succedendo, turno sulla output dettagliato e vedere tutti i parametri per te).

Se avete bisogno di costruire un riferimento incrociato di ciò che chiama quello, il comando UNIX Services "nm" può dare quelle informazioni. Se si producono dettagliate collegamento Modifica elenchi, tutti i dati sono lì anche quando si sta costruendo le DLL.

In bocca al lupo!