Στις 3 Οκτωβρίου 2011 3:28 μ.μ., ο χρήστης John Tsiombikas <nuclear [ at ] member [ dot ] fsf [ dot ] org> έγραψε: > On Mon, Oct 03, 2011 at 07:07:29AM +0300, Nick Kossifidis wrote: >> >> Στις 2 Οκτωβρίου 2011 7:31 μ.μ., ο χρήστης John Tsiombikas >> > >> > 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 > > Profanos den katalabes. > > Kanoume compile: gcc $CFLAGS -c foo.c > Kanoume link: gcc -o binary foo.o $LDFLAGS > > Otan kaneis *compile* pernas to apotelesma tis pkg-config --cflags ston > compiler to opoio periexei include paths (-I) kai defines (-D) synithos. > > Otan kaneis *link* pernas to apotelesma tis pkg-config --libs ston > compiler to opoio periexei library paths (-L) kai ti na kanei link (-l). > > Den pernas linker flags ston compiler otan kaneis compiler ena source > file gia na bgaleis ena object file. > Κι εσύ μάλλον δεν κατάλαβες τι ρώτησα, το: gcc $LDFLAGS -o binary foo.o δουλεύει σε προηγούμενες εκδόσεις του gcc και όχι στην gcc 4.6 και για να σου φύγει και το κόλλημα, το pkg-config --cflags --libs openssl libcurl δεν επιστρέφει καν cflags (είναι στο default include path ούτως ή άλλως), μόνο libs mick@gazofonias ~ $ pkg-config --cflags --libs openssl libcurl -lssl -lcrypto -ldl -lz -lcurl πραγματικά το όνομα της μεταβλητής κλπ δεν έχει σημασία, είναι μια σύμβαση (ο gcc κρατάει ότι τον ενδιαφέρει κάθε φορά και αγνοεί τα υπόλοιπα), το φαινόμενο είναι ότι ο καινούριος gcc για κάποιο λόγο δέχεται τα arguments μόνο στο τέλος της εντολής και όχι στην αρχή και απλά ρώτησα αν έχει δει κανείς κάτι αντίστοιχο (διαφορετική συμπεριφορά στη σειρά των arguments). Ούτε αν είναι σωστό το temp scriptάκι μου για να κάνω build, ούτε πώς κάνουμε compile και link κλπ. >> >> Το θέμα μου δεν είναι να μου κάνετε 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 ? > > Giati aytos einai o tropos pou doulevoun ta memory corruption bugs. > Mporei na skaei kathe 3i pempti tou mina mono otan exeis eggatestimeno > to libxcb 3.4 ston ypologisti sou pou den to kaneis kan link. > > Min prospatheis na breis tipota allo prin lyseis ta bugs sou. Ginese > kourastikos. > Με τη διαφορά ότι o allocator της glibc είναι per execution thread (ptmalloc) οπότε δεν επηρεάζεται από άλλα procs που τρέχουν στο σύστημα (εκτός ποια αν έχει πρόβλημα το memory management στον πυρήνα και η mmap) + χρησιμοποιώ τις ίδιες εκδόσεις των βιβλιοθηκών με τις οποίες κάνω link (γι' αυτό και δεν το ανέφερα καν). Επίσης τα 4 bytes (sizeof(int) στο σύστημά μου) και το μέγεθος του struct μου πέφτουν στη ίδια κατηγορία του allocator (<= 64bytes) οπότε η συμπεριφορά του θα έπρεπε να είναι ίδια (http://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;hb=HEAD). -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick