Δείτε εδώ τα πιο πρόσφατα μηνύματα από όλες τις περιοχές συζητήσεων, καθώς και όλες τις υπηρεσίες της AcroBase. H εγγραφή σας είναι γρήγορη και εύκολη. |
|
Κεντρική σελίδα |
Λίστα Μελών | Games | Σημειώστε όλα τα forums ως διαβασμένα | Σημειώστε όλα τα forums ως διαβασμένα |
|
|
Εργαλεία Θεμάτων | Τρόποι εμφάνισης |
#1
|
#2
|
|
||||
Α, συμφωνα με τις οδηγιες του βιβλιου, μολις εκανα compile τα kernel headers, εσβησα τα source.
Διαβασα ομως αργοτερα οτι ο κωδικας του κερνελ χρειαζονται να υπαρχει οταν κανουμε compile σε καποια πακετα. Ξερετε αν τα glibc εξαρτωνται απο το source του kernel?
__________________
Υπάρχουν σε όλα δύο απόψεις... Αυτή που λέω εγώ, και η σωστή! Τελευταία επεξεργασία από το χρήστη Gildor : 15-11-08 στις 20:56 |
#3
|
|
||||
Τελικα δεν επιασε αυτο. Ειπα να κανω επαναληψη στη διαδικασια, και οταν εκανα configure ειδα αυτο το μηνυμα
cannot compute sizeof (long doube), 77
__________________
Υπάρχουν σε όλα δύο απόψεις... Αυτή που λέω εγώ, και η σωστή! |
#4
|
|
||||
τι γραφεις προς τον εαυτο σου με τοση απελπισια;;
αφου ξερεις οτι μονο ενας μπορει να σου λυσει το προβλημα.. και το ξερεις αυτο καλυτερα απο εμενα... αρχισε τις επικλισεις στoν μεγαλο γκουρου...
__________________
μιαπαπιαμαποιαπαπια Τελευταία επεξεργασία από το χρήστη papa : 16-11-08 στις 12:22 |
#5
|
|
|||
Ισως όχι όλος ο kernel αλλά τα header files μόνο.
|
#6
|
|
||||
Exit code 2 = κάποιο από τα προγράμματα που εκτελεί το make επέστρεψε exit code 2 (0 = όλα καλά, όλα τα άλλα εξαρτώνται από το συγκεκριμένο πρόγραμμα). Δες τα logs για να δεις τι φταίει. Αν μιλάμε για error 2, αυτό είναι ENOENT, που συνήθως σημαίνει «File not found». Ένας κατάλογος υπάρχει στο /usr/include/asm-generic/errno-base.h. Το τι ακριβώς σημαίνει κάθε errno εξαρτάται από το system call που εκτελείται. Πχ το open(2) system call (που ανοίγει αρχεία) εννοεί File Not Found. Άλλα system calls μπορεί να εννοούν άλλα πράγματα, αν και συνήθως θα είναι κάτι πολύ παρόμοιο — δες τη σελίδα του κάθε system call (πχ man 2 open) για πληροφορίες, οι κωδικοί λαθών τεκμηριώνονται πάντα. Τα ευγενικά προγράμματα εξηγούν τι σημαίνει κάθε λάθος, συνήθως δίνοντας κωδικό και και εξήγηση: Error 2: file not found. Μια καλή πρακτική είναι όταν χτίζεις τεράστια προγράμματα/βιβλιοθήκες: Κώδικας:
make μπλα μπλα 2>&1 | tee build.log Με αυτό το μαγικό μπορείς να ανατρέξεις αργότερα στο build.log και να δεις ακριβώς τι έσκασε και πού. ...πράγμα που είναι χρήσιμο για να δούμε τι παίζει εδώ.
__________________
www.bedroomlan.org |
#7
|
|
||||
Δεν ξέρω ποια είναι η σωστή. Υπάρχουν αρκετές ενδείξεις ότι είναι bug όμως (κι όχι δικό σου φταίξιμο), οπότε δοκίμασε να χτίσεις την τελευταία έκδοση της glibc. Δε θα το μετανιώσεις. Από περιέργεια: γιατί μαζοχίζεσαι με το Linux from Scratch; Ελπίζω όχι για πρακτική χρησιμότητα, μια και μέχρι να το χτίσεις όλο, θα έχουν βγει security updates και bug fixes και θα πρέπει να ξαναξεκινήσεις.
__________________
www.bedroomlan.org |
#8
|
|
||||
Λεπον
ενας ανθρωπος μου ειπε να κανω
Το γιατι δεν υπαρχει ενω επρεπε να υπαρχει, ειναι αλλη ιστορια Δεν ξερω γιατι ελειπε αυτο το αρχειο, αλλα εκανα ενα ln με το αναλογο αρχειο στο /lib και το configure proxvrhse kanonika ΠΡος το παρον εξηγειστε μου αν εχετε χρονο τι εκανε η παραπανω εντολη :Ρ
__________________
Υπάρχουν σε όλα δύο απόψεις... Αυτή που λέω εγώ, και η σωστή! |
#9
|
|
||||
Κώδικας:
echo -e "#include Κώδικας:
cat < Μπορείς να κάνεις cut & paste ακριβώς τι βγάζει; Ξέρω ότι είναι τεράστια... Η κατά συνθήκη θέση του dynamic loader είναι στο /lib: Κώδικας:
$ ls -la /lib/ld-* -rwxr-xr-x 1 root root 113248 Jul 29 08:21 /lib/ld-2.7.so* lrwxrwxrwx 1 root root 9 Sep 30 00:53 /lib/ld-linux.so.2 -> ld-2.7.so* Η απορία είναι σε ποιο στάδιο το Linux from Scratch σου ζητάει να χτίσεις τον dynamic loader. Η απορία μου είναι λίγο περίεργη, γιατί νομίζω ότι ο ld-linux ανήκει στο libc (δηλαδή είναι μέρος του glibc που χτίζεις τώρα). Δηλαδή πρόβλημα κότας κι αυγού. Αν το glibc χρειάζεται ld-linux για να χτιστεί, και το glibc χτίζει το ld-linux, τότε πώς κάνεις bootstrap το λειτουργικό; Υπ'όψη ότι η τελευταία φορά που έχτισα libc ήταν όταν είχα AMD K5 και δεν υπήρχαν K5-optimised βιβλιοθήκες. Πάνε αρκετά χρόνια από το 1997... Οπότε μπορείς να θεωρήσεις ότι είμαι άσχετος ως προς το τελευταίο ερώτημά μου.
__________________
www.bedroomlan.org |
#10
|
|
||||
Για να δουμε...
επιστρεφω λιγο στο προβλημα για να δω τι συνεβη... Το gcc που χρησιμοποιω για την εγκατασταση του lfs το εκανα compile ο ιδιος συμφωνα με τις οδηγιες μου ειπαν οτι αν γραψουμε
με τι options πρεπει να εκανα configure το gcc που μολις εκανα compile ωστε να ψαχνει το αρχειο στο /tools/lib και οχι στο /lib? Οι options που εβαλα ηταν
Ναι οκ θα μου πειτε οτι αφου εκανα το ln ειναι ολα οκ, γιατι σκαω; Το θεμα ομως ειναι να ξερω αν εκανα λαθος και που, και αν δεν εκανα εγω λαθος, να ξερω να βρισω αυτους που εγραψαν τις οδηγιες :Ρ
__________________
Υπάρχουν σε όλα δύο απόψεις... Αυτή που λέω εγώ, και η σωστή! Τελευταία επεξεργασία από το χρήστη Gildor : 19-11-08 στις 00:47 |
#11
|
|
||||
'Εχω μια χαζοέξυπνη ερώτηση.
Το σύστημά σου έχει gcc installed (προφανώς, γιατί με αυτόν έκανες compile τον εαυτό του). Ποιος gcc είναι αυτός που εκτελείς όταν γράφεις gcc; Πες Κώδικας:
type gcc Κώδικας:
export PATH=/usr/local/papaki/bin:$PATH
__________________
www.bedroomlan.org |
#12
|
|
||||
τελικα χωρις να αλλαξω τιποτα (ουτε καν ln) εκανα κανονικα compile to glibc χωρις το προηγουμενο προβλημα
οποτε το προβλημα την πρωτη φορα ειχε μια απο τις εξης εξηγησεις 1. το ld-linux.so.2 πηγε σε λαθος μερος (δεν ξερω που επρεπε να ειναι) 2. το gcc μεταγλωττιστηκε με λαθος και κοιταζε για το ld-linux.so.2 σε λαθος μερος (δεν ξερω που επρεπε να κοιταζει) 3. ολα τα παραπανω 4. κανενα απο τα δυο Για καποιο λογο στο δευτερο περασμα εγινε "σωστα", ολα πηγαν στη θεση τους και αυτο φανηκε με το τελευταιο compile... οποτε υποθετω δε χρειαζεται απαντηση στις ερωτησεις σχολιο: ουγκ
__________________
Υπάρχουν σε όλα δύο απόψεις... Αυτή που λέω εγώ, και η σωστή! Τελευταία επεξεργασία από το χρήστη Gildor : 19-11-08 στις 16:43 |
#13
|
|
||||
Αυτό που δεν κατάλαβα εγώ είναι αν πέρα από την πλάκα υπάρχει άλλος λόγος για να τα κάνεις όλα αυτά!
Επίσης, μινι-ερώτηση, στο πρόγραμμα δε θα έπρεπε να είναι printf("%d\n", sizeof(long double)); αντί για σκέτο sizeof(long); (<-- εδώ το ; δηλώνει ερώτηση και όχι σύνταξη της C)
__________________
may you live in interesting times |
#14
|
|
||||
να, οριστε, σημερα εμαθα τι ειναι το ld-linux.so.2... αμα πια
__________________
Υπάρχουν σε όλα δύο απόψεις... Αυτή που λέω εγώ, και η σωστή! Τελευταία επεξεργασία από το χρήστη Gildor : 19-11-08 στις 17:34 |
#15
|
|
||||
Ακόμα χειρότερα, έκανα compile το πρόγραμμα (σε assembly) και κοίταξα τον object code. Το statement sizeof (long); δεν υπάρχει καθόλου μέσα στον assembly κώδικα. Πράγμα καθόλου περίεργο, μια και δεν κάνει απολύτως τίποτα (warning: statement without effect) και ο compiler το κάνει optimise. Αλλά νομίζω ότι το πρόγραμμα θα ψόφαγε έτσι κι αλλιώς, είτε έκανες sizeof (long); είτε sizeof (long double); είτε ακόμα και printf ("%d\n", sizeof (long double)); ή printf ("Hello World!\n"); Γιατί τελικά η υπόθεση ήταν λάθος. Το πρόβλημα δεν είναι ότι ο compiler δε μπορεί να υπολογίσει ένα sizeof. Το sizeof δεν είναι συνάρτηση. Οι τιμές που επιστρέφει βρίσκονται σ'έναν πίνακα που εξαρτάται από την αρχιτεκτονική σου. Όποτε ζητάς ένα sizeof απλού τύπου (char, short, int, long, long long, float, double, long double), ο compiler αντικαθιστά το sizeof(x) με μια σταθερά. Αυτό φαίνεται στην assembly του printf ("%d\n", sizeof (long double));: Κώδικας:
.LCFI1: movl $16, %esi # το sizeof (long double) movl $.LC0, %edi # το string "%d\n" movl $0, %eax call printf leave ret Άρα το πρόβλημα δεν ήταν στο compilation. Ο C compiler δε μπορεί να μην ξέρει τα μεγέθη των βασικών του τύπων. Το πρόβλημα ήταν απλό, διαφορετικό και παραπλανητικό: το πρόγραμμα (που είναι ένα από τα βασικά test του GNU Autoconf, aka configure) δε μπορούσε να γίνει linked επειδή ο linker δε μπορούσε να βρει το ld-linux.so. Χωρίς το πρόγραμμα, το test αποτυγχάνει, και το configure πετάει το μήνυμα που πετάει σε περίπτωση αποτυχίας: "cannot calculate sizeof long double". Υπάρχει ένα άλλο στάνταρ test που ελέγχει αν ο compiler μπορεί να χτίσει προγράμματα (λέει κάτι σαν «Checking if the compiler can produce executables»). Αν βάλεις αυτό κάπου στην αρχή, πιάνει το υποβόσκον πρόβλημα και σου λέει από νωρίς ότι όχι, ο compiler σου είναι ανίκανος να χτίσει ακόμα και το απλούστερο πρόγραμμα. Προφανώς αυτό το test δεν περιλαμβάνεται στη glibc, αλλά πόσα συστήματα είναι ικανά να φτάσουν στο σημείο να τρέχουν ένα autoconf script χωρίς dynamic loader; (απάντηση: όλα τα αρχαία Unix με μόνο static binaries, αλλά σ'αυτά δε δουλεύει η glibc έτσι κι αλλιώς). Μη βαράς! Εσύ εξέφρασες περιέργεια!
__________________
www.bedroomlan.org |
Συνδεδεμένοι χρήστες που διαβάζουν αυτό το θέμα: 1 (0 μέλη και 1 επισκέπτες) | |
Εργαλεία Θεμάτων | |
Τρόποι εμφάνισης | |
|
|