Come faccio a soddisfare un 3rd-party condivisa riferimento alla libreria di stat quando sto creando uno spessore libreria condivisa, piuttosto che un file eseguibile?

Question

Sono il nuovo manutentore per un sistema Python in-casa che utilizza un insieme di 3rd-party ha condiviso le librerie C tramite uno spessore libreria condivisa che viene creato utilizzando una combinazione di sorso e uno script setup.py. Questo ha funzionato bene fino a poco tempo.

Il 3rd-party condiviso librerie C sono stati aggiornati per nuove funzionalità e ora ottengo il seguente errore di run-time, dopo una generazione pulita, quando si tenta di eseguire il nostro programma Python principale (che importa il generato spessore libreria condivisa):

-sh-3.00 $ python ams.py

ImportError: /usr/lib/libz4lnx.so: undefined symbol: stat

Ho trovato un thread di discussione a partire dal 1999 che spiega che il problema è che non è stat presente in libc.so.6, ma piuttosto in libc_nonshared.a, e fornisce una soluzione: Link contro la libreria C, con l'aggiunta di -lc alla riga di comando di compilazione.

http://www.redhat.com/archives/pam-list/1999-February/msg00082.html

ho aggiunto 'C' per l'elenco delle librerie nello script setup.py, ma questo non cambia i miei risultati. Ho il sospetto che questo è perché io sono la creazione di uno spessore libreria condivisa, piuttosto che un eseguibile.

Come posso soddisfare la 3rd-party condiviso il riferimento di libreria per stat, dato il mio ambiente di sviluppo?

Il mio sistema di compilazione è:

-sh-3.00 $ lsb_release -a

LSB Version:    :core-3.0-ia32:core-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch
Distributor ID: CentOS
Description:    CentOS release 4.6 (Final)
Release:        4.6
Codename:       Final

La mia versione gcc è:

-sh-3.00 $ gcc version

gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-10)

La mia versione di Python è:

-sh-3.00 $ python -V

Python 2.3.4

Answer 1

Come si è visto, mentre si muove a CentOS 5.3 è stata probabilmente una buona cosa a lungo andare, il problema reale risulta essere stato il modo in cui è stato costruito libz4lnx sul DVD che stavo usando in origine. Nel processo di spostamento a CentOS 5.3, ho anche spostato in una build più recente della biblioteca libz4lnx. Oggi, durante la prova di qualcosa d'altro, ho usato la libreria dal DVD originale ed ho ottenuto lo stesso identico errore di simbolo indefinito durante l'esecuzione del programma Python. Ritornando alla nuova DVD (circa due mesi più recenti) risolto ancora il problema.

Answer 2

La soluzione era quella di creare un nuovo CentOS 5.3 VM e ri-costruire e / o reinstallare i componenti, se necessario.