Ένα από τα πράγματα που με εκνευρίζουν είναι όταν οι developers ΔΕΝ ξέρουν τι κάνουν.
Και παραθέτω το εξής: η βιβλιοθήκη jpeg έχει φτάσει στην έκδοση 7
Όταν ένας developer θέλει να ελέγξει ή να κάνει χρήση της βιβλιοθήκης τότε απλά πρέπει να προσθέσει το εξής: -ljpeg κατά το compilation.
Οι περισσότερες διανομές έχουν την εξής βιβλιοθήκη: libjpeg ή jpeg-dev ή κάπως έτσι.
Αυτό που χρειαζόμαστε πραγματικά είναι η ύπαρξη της εξής βιβλιοθήκης:
[ebal@myhome:~]€ ldd /usr/lib/libjpeg.so
linux-gate.so.1 => (0xb7fe8000)
libc.so.6 => /lib/libc.so.6 (0xb7e54000)
/lib/ld-linux.so.2 (0xb7fe9000)
η οποία είναι συνήθως (99%) link στην αντίστοιχη έκδοση:
[ebal@myhome:~]€ ls -l /usr/lib/libjpeg.so
lrwxrwxrwx 1 root root 16 2009-06-27 12:54 /usr/lib/libjpeg.so -> libjpeg.so.7.0.0
Τώρα γιατί ΜΑ ΓΙΑΤΙ ένας developer να έχει ορίσει το libjpeg.so.62 με το χέρι στον κώδικά του δεν μπορώ να το καταλάβω?
Το αποτέλεσμα είναι το παρακάτω γελοίο μήνυμα:
error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory
Στο παραπάνω πρόβλημα σκέφτηκα τρεις (3) λύσεις :
a. ln -s /usr/lib/libjpeg.so /usr/lib/libjpeg.so.62
b. downgrade σε libjpeg.so.62
c. edit source code και rebuild όλα τα source προγράμματα !
Η έκδοση 7 περιέχει αλλαγές και προσθήκες αλλά όχι αλλαγή αρχιτεκτονικής, η δημιουργία ενός συνδέσμου (επιλογή a) και ένα email στον αρχικό δημιουργό ώστε να τροποποιήσει εκείνος τον κώδικά του σε κάτι πιο ….. σωστό μου φάνηκε ο πιο γρήγορος κι εύκολος τρόπος.
Φυσικά τέτοια προβλήματα είναι το τίμημα όταν έχεις πάντα ένα υβριδικό μοντέλο μίας base διανομής και όλα τα υπόλοιπα να είναι built from scratch
Δυστυχώς ΔΕΝ έχω ακόμα βρει (δεν ξέρω φυσικά εάν θα την βρω και ποτέ) την υπέρτατη τέλεια διανομή.
ΥΓ: το παραπάνω πρόβλημα είναι ένα από τα “κλασικά” όταν κάνεις update ή όταν θέλεις να είσαι bleeding edge (ή κοινός να έχει τόσο ελεύθερο χρόνο ώστε να κάνει το testing σε unstable προγράμματα).