Στις 3 Οκτωβρίου 2011 6:09 π.μ., ο χρήστης John Tsiombikas <nuclear [ at ] member [ dot ] fsf [ dot ] org> έγραψε: > Katarxas kalytera min apantas me "to" emena kai "cc" tin lista, spas to > list-reply tou client. > Default του gmail, και μόνο που η λίστα έχει 2 addresses απ' ότι φαίνεται σπάει το list-reply (εγώ έστειλα στο @grnet.gr και εσύ στο @ellak.gr) οπότε δεν ασχολήθηκα και ιδιαίτερα. Σε άλλες λίστες που είμαι δεν υπήρξε μέχρι τώρα κάποιο πρόβλημα και by default όλοι έτσι απαντούν (νομίζω και το mutt το ίδιο κάνει). > On Mon, Oct 03, 2011 at 05:36:42AM +0300, Nick Kossifidis wrote: >> Στις 2 Οκτωβρίου 2011 7:31 μ.μ., ο χρήστης John Tsiombikas >> <nuclear [ at ] member [ dot ] fsf [ dot ] org> έγραψε: >> > On Sun, Oct 02, 2011 at 04:48:24PM +0300, Nick Kossifidis wrote: >> >> gcc $CFLAGS -c foo.c -o bar.o >> >> δεν κάνει ποτέ link (το bar.o είναι linked μόνο με τη libc και όλα τα >> >> symols προς άλλες βιβλιοθήκες είναι unresolved), ενώ το >> >> gcc -c foo.c -o bar.o $CFLAGS >> >> δουλεύει κανονικά ! >> > >> > Den mas eipes ti periexei to CFLAGS omos ... >> > >> >> Ότι περιέχει συνήθως (http://en.wikipedia.org/wiki/CFLAGS), στη δικιά >> μου περίπτωση είναι απλά το output του package config για τις >> βιβλιοθήκες που χρησιμοποιώ (ούτε optimizations ούτε τίποτα περίεργο), >> ποιο συγκεκριμένα... >> >> `pkg-config --cflags --libs openssl libcurl` > > To CFLAGS *DEN* periexei kanonika to output tou pkg-config --libs se > kamia periptosi. Perna to --cflags sto CFLAGS kai to --libs sto LDFLAGS > kai de tha exeis tetoia provlimata. > >> Τελικά το άφησα έτσι για να δουλεύει παντού, απλά μου κάνει εντύπωση >> και ρωτάω αν το έχει δει κανείς. > > Oxi giati kaneis den pernaei to output tou pkg-config --libs sto CFLAGS. > Το θέμα είναι το όνομα της μεταβλητής ή ότι μέχρι τώρα έβαζα τα συγκεκριμένα arguments στην αρχή της εντολής και δούλευε και στον 4.6 που δοκίμασα δε δουλεύει ? Το θες αλλιώς ? Το gcc $CFLAGS $LDFLAGS -c foo.c -o bar.o δούλευε πριν και τώρα δουλεύει μόνο το gcc -c foo.c -o bar.o $CFLAGS $LDFLAGS >> > Den mas edoses backtrace omos apo ton gdb ... >> >> Το θέμα μου δεν είναι να μου κάνετε debug, το κάνω και μόνος μου (θα > > Den fainese diatethimenos na to kaneis, protimas na ta rikseis sto > ubuntu, ston gcc kai se otidipote allo breis mprosta sou eno poly apla > exeis kapoio memory corrupting bug. > Και ξαναρωτάω γιατί πραγματικά δε πιστεύω ότι γράφω Κινέζικα, πού ακριβώς λέω ότι φταίει κάτι/κάποιος ? Απλά ρωτάω αν έχετε δει κάτι αντίστοιχο ! Έστω ότι έχω memory corrupting bug, γιατί στον 4.4.6 και στον 4.5.2 δε φαίνεται και όλα δουλεύουν μια χαρά και φαίνεται στον 4.6 ? > To point mou itan oti me tis plirofories pou edoses den yparxei > periptosi na pareis xrisimi apantisi. Kai nai kata pasa pithanotita mono > me ena backtrace de tha mporousa na sou po tipota idietera xrisimo > episis, alla ksekinontas apo to backtrace i logiki mou itan na se balo > stin diadikasia na koitakseis ton kodika sou anti na ta rixneis ston > gcc. > Λες να μην τον κοίταξα ? Σου λέω ότι παίζει κανονικά με 4.4.6 και 4.5.2 και σε 32bit και σε 64bit και βλέπω να έχει αυτό το πρόβλημα στον 4.6. Με τις πληροφορίες που έδωσα δε ζήτησα ούτε debuging ούτε τίποτα, απλά ρώτησα αν έχετε δει με τον 4.6 τέτοιες αλλαγές στη συμπεριφορά του compiler και μια χρήσιμη απάντηση θα ήταν ένα ναι ένα όχι ή ένα ίσως (ως χρήσιμη απάντηση ορίζω την απάντηση στην ερώτηση την οποία έκανα), τίποτα ποιο πολύπλοκο. >> όρους) -προφανώς τα 2 συστήματα διαφέρουν αρκετά, το ένα έχει 2 cores >> ενώ το άλλο όχι, διαφορετική αρχιτεκτονική κλπ οπότε είναι λογικό σε >> ένα malloc pool corruption να μην έχουν την ίδια συμπεριφορά. Αν τώρα >> αλλάξω το sizeof(int) και το κάνω sizeof(struct kati) -που είναι >> προφανώς το σωστό code-wise- το πρόγραμμα δε βαράει segfault και >> παίζει κανονικά. Υπόψη το kati1 δε το χρησιμοποιώ στη συνάρτηση, απλά >> το κάνω malloc/memset (αλλά Ο.Κ. στο malloc pool αυτό δεν έχει σημασία >> γιατί είναι το αμέσως προηγούμενο malloc, γι' αυτό και λέω "λιγότερο >> κουλό"). Απλά δε καταλαβαίνω τι το κόφτει αν είναι sizeof(int) και όχι >> sizeof(struct kati1) αφού ούτως η άλλως η malloc επιστρέφει έναν void >> pointer, να χτύπαγε όταν πήγαινα να γεμίσω το kati1 να το καταλάβαινα >> αλλά βαράει στο επόμενο malloc ουσιαστικά, χωρίς να χρησιμοποιώ το >> kati1 πουθενά -ήταν work in progress-. > > Min prospatheis na breis tetoiou eidous logiki, profanos gia to struct > kanei allocate allo megethos, allazoun polla. Trekse ena valgrind an den > mporeis na breis pou einai to provlima diabazontas ton kodika. > Το πρόβλημα στον κώδικα όπως γράφω και παραπάνω το διόρθωσα και έφυγε και το segfault, το πρόβλημα το δικό μου είναι ότι θεωρητικά αυτά τα δύο είναι ασύνδετα. Θα έτρεχα memcheck κλπ αλλά όταν κάνεις link με την openssl και δεν την έχεις κάνει compile με το purify option γίνεται της κακομοίρας και δε βγάζεις άκρη (η openssl για λόγους randomization και λόγω της cross-platform αρχιτεκτονικής της χρησιμοποιεί uninitialized κομμάτια μνήμης κλπ τα οποία δεν αρέσουν -και λογικά- στο memcheck, σου θυμίζω το κλασσικό σκηνικό με το debian), για την ώρα δε με βολεύει να ξανακάνω compile την openssl στο ubuntu και αφού το bug δεν υπάρχει ποια + ούτως ή άλλως θα κάνω memcheck κλπ όταν τελειώσω το κομμάτι του κώδικα που γράφω προτιμώ να δω το πρόβλημα ανεξάρτητα απ' τον κώδικά μου, γι' αυτό είπα και για ένα προγραμματάκι για να testάρω μόνο αυτό. anyway καλό ξημέρωμα ;-) -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick