Katarxas kalytera min apantas me "to" emena kai "cc" tin lista, spas to list-reply tou client. 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. > > 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. 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. > όρους) -προφανώς τα 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. -- John Tsiombikas http://nuclear.mutantstargoat.com/