maker error - recompile with -fPIC

[chek2fire]

Για πείτε παιδιά καμιά ιδέα γιατί προσπαθώ να κάνω compile ένα πρόγραμμα και μου βγάζει στο τέλος το make αυτό εδώ το error

relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE

τωρα από όσo έχω ψάξει όλοι προτείνουν αυτό που λέει δλδ να το κάνω recompile και αρχικά στο configure να βάλω και την παράμετρο -fPIE.

To θέμα είναι το configure δεν έχει κάτι τέτοιο

[dancer_69]

Το να έλεγες και για ποιο πρόγραμμα πρόκειται δε θα έβλαπτε.

Πάντως σε τέτοιες περιπτώσεις, πρώτα κοιτάς στη σελίδα του προγράμματος, για τα dependencies του καθώς και στα issues(αφού το πιθανότερο είναι να στο github), μήπως υπάρχει ήδη κάποια αναφορά. Επίσης κάνεις μια αναζήτηση στο google με το σφάλμα που σου βγάζει.

Για την περίπτωσή σου βρήκα αυτό:

https://stackoverflow.com/questions/19364969/compilation-fails-with-relocation-r-x86-64-32-against-rodata-str1-8-can-not

όπου φαίνεται πως είναι αρκετά παρόμοια περίπτωση. Έχει λοιπόν κάποιες λύσεις στα σχόλια που μπορείς να δοκιμάσεις.

Επεξ/σία 21 Μαΐου 2020 από dancer_69

[chek2fire]

και να σου πω το πρόγραμμα δεν έχει καμία ουσία καθώς δεν είναι από τα γνωστά προγράμματα. 

Είναι το lightningd 

https://github.com/ElementsProject/lightning

η απορία που έχω είναι πως βάζουν όλα αυτά τα flag στο configure και εγώ  δεν μπορώ να βάλω τιποτα και το help δλδ δεν εμφανίζει τέτοιες επιλογές.

Δλδ στο link που μου έδωσες κάποιος λέει ότι έκανε το configure με αυτό εδώ --disable-shared

Σε μένα το βγάζει unknown option

[mphxths]

@chek2fire

Λοιπον , εχουμε και λεμε  Ξεκιναμε απο το γεγονος οτι υπαρχουν τεσσερις τροποι να εγκαταστησεις αυτο το προγραμμα.Εσυ λες δεν γαμιεται το ppa και τα binaries...παμε να παιξουμε με compiles.

Για το compile , ακολουθησες τις οδηγιες εδω ?  Λινκαρω για ubuntu γιατι ξερω οτι εισαι παιδι του ubuntu  Εγω λοιπον που τις ακολουθησα , εγινε κανονικα το compile σε εγκατασταση ubuntu 20.04 . 
Πριν το "configure" , ξηγηθηκα ενα "make clean" καλου κακου..

[chek2fire]

κάτσε να σου πω το ιστορικό. Αυτό το πρόγραμμα το τρέχω εδώ και δύο χρόνια στο ubuntu 18.04 σε ένα υπολογιστή που έχω για server. Δλδ μέχρι τότε έτρεχε μια χαρά και με συχνά git pull. 

Πριν τρεις μέρες είπα να αναβαθμίσω σε 20.04 και μια και αναβάθμισα είπα να κάνω ξανά compile το πρόγραμμα και τότε εμφανίστηκε αυτό.

[mphxths]

5 ώρες πριν, chek2fire είπε

κάτσε να σου πω το ιστορικό. Αυτό το πρόγραμμα το τρέχω εδώ και δύο χρόνια στο ubuntu 18.04 σε ένα υπολογιστή που έχω για server. Δλδ μέχρι τότε έτρεχε μια χαρά και με συχνά git pull. 

Πριν τρεις μέρες είπα να αναβαθμίσω σε 20.04 και μια και αναβάθμισα είπα να κάνω ξανά compile το πρόγραμμα και τότε εμφανίστηκε αυτό.

Ακολουθα τις οδηγιες.Οπως ειπα εμενα σε σχετικα καθαρη εγκατασταση 20.04 δεν εβγαλε κανενα απολυτως προβλημα.Απο την αλλη γιατι δεν το τσιμπας απο το ppa ?

ΥΓ : το bitcoin που αναφερει εκει στις οδηγιες...δεν εχει απο ο,τι καταλαβα ακομα ρεπο για το "focal"...

[chek2fire]

το bitcoin ppa έχει να αναβαθμιστεί από το 17 

[imitheos]

21 ώρες πριν, chek2fire είπε

Για πείτε παιδιά καμιά ιδέα γιατί προσπαθώ να κάνω compile ένα πρόγραμμα και μου βγάζει στο τέλος το make αυτό εδώ το error

relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE

τωρα από όσo έχω ψάξει όλοι προτείνουν αυτό που λέει δλδ να το κάνω recompile και αρχικά στο configure να βάλω και την παράμετρο -fPIE.

To θέμα είναι το configure δεν έχει κάτι τέτοιο

Σε ένα σωστά στημένο σύστημα δεν θα έπρεπε να στο βγάζει αυτό. Το PI σημαίνει position independent δηλαδή ο κώδικας είναι χτισμένος έτσι ώστε να μην έχει hardcoded διευθύνσεις αλλά να χρησιμοποιεί ένα register και να γίνονται όλα έμμεσα μέσω αυτού. Σε 32bit αυτό δεν πολυχρησιμοποιούταν επειδή μείωνε τις επιδόσεις. Εδώ να πούμε ότι οι βιβλιοθήκες λόγω του τρόπου που δουλεύουν πάντα χρησιμοποιούσαν position independent κώδικα.

Κάποια στιγμή (ειδικά όταν άρχισε να γίνονται δημοφιλή τα 64bit) άρχισαν όλοι να χτίζουν PI για μεγαλύτερη ασφάλεια. Το πρόβλημα τώρα δημιουργείται επειδή υπάρχουν δύο τρόποι υλοποίησης. Ο ένας είναι PIC (code) ο οποίος μπορεί να χρησιμοποιηθεί στις βιβλιοθήκες και ο PIE (executable) που μπορεί να χρησιμοποιηθεί στα εκτελέσιμα. Όταν λοιπόν άρχισαν όλοι να προσθέτουν στις CFLAGS τους το -fPIC, έπαιρναν τέτοια μηνύματα. Δεν γίνεται λοιπόν να βάλει κάποιος άιντε χύμα στην CFLAGS το fPIC ή το fPIE και τελείωσε. Ο τρόπος που υλοποιείται από τις διανομές είναι μέσω του spec του compiler το οποίο έχει μέσα δομές if οι οποίες του λένε "θέλει ο χρήστης PIC" -> Αν ναι, δες για τι object μιλάμε -> Είναι βιβλιοθήκη ; Τότε PIC αλλιώς PIE.

Αυτό ιστορικά - εγκυκλοπαιδικά.

Τώρα όσον αφορά το configure, το PIE δεν είναι επιλογή του configure αλλά του compiler για αυτό δεν το βρίσκεις. Στο τερματικό που πας να χτίσεις το πρόγραμμα, πριν τρέξεις το configure, δες τι τιμή έχουν οι μεταβλητές CFLAGS, CXXFLAGS. Λλογικά δεν πρέπει να έχουν τιμή αλλά αν έχουν μέσα το fPIC βγάλε το. Αλλιώς μπορείς πριν τρέξεις το configure να τρέξεις export CFLAGS="-O2 -pipe -fPIC -fPIE" και το ίδιο στο CXXFLAGS και να τρέξεις μετά το configure να δεις αν λειτουργεί. Πάνε χρόνια από τότε που ήταν κοινό πρόβλημα και δεν πολύ θυμάμαι αλλά έχω την εντύπωση ότι όταν έδινες μόνο το PIE (ή και τα δύο), επέλεγε το σωστό ανάλογα την περίπτωση. Πιθανώς να μην λειτουργήσει αλλά και πάλι δεν θα έπρεπε καν να υπάρχει το παραπάνω πρόβλημα (ειδικά σήμερα).

Δεν γνωρίζω από ubuntu οπότε ίσως κάποιος άλλος να δώσει πιο σωστές πληροφορίες.

Επεξ/σία 22 Μαΐου 2020 από imitheos

[Επισκέπτης]

να σου πω επειδή διαβάζω καιρό τώρα τα post σου, μια προτροπή, βγάλε το ημι (imi) από το nickname σου

[chek2fire]

2 ώρες πριν, imitheos είπε

Σε ένα σωστά στημένο σύστημα δεν θα έπρεπε να στο βγάζει αυτό. Το PI σημαίνει position independent δηλαδή ο κώδικας είναι χτισμένος έτσι ώστε να μην έχει hardcoded διευθύνσεις αλλά να χρησιμοποιεί ένα register και να γίνονται όλα έμμεσα μέσω αυτού. Σε 32bit αυτό δεν πολυχρησιμοποιούταν επειδή μείωνε τις επιδόσεις. Εδώ να πούμε ότι οι βιβλιοθήκες λόγω του τρόπου που δουλεύουν πάντα χρησιμοποιούσαν position independent κώδικα.

Κάποια στιγμή (ειδικά όταν άρχισε να γίνονται δημοφιλή τα 64bit) άρχισαν όλοι να χτίζουν PI για μεγαλύτερη ασφάλεια. Το πρόβλημα τώρα δημιουργείται επειδή υπάρχουν δύο τρόποι υλοποίησης. Ο ένας είναι PIC (code) ο οποίος μπορεί να χρησιμοποιηθεί στις βιβλιοθήκες και ο PIE (executable) που μπορεί να χρησιμοποιηθεί στα εκτελέσιμα. Όταν λοιπόν άρχισαν όλοι να προσθέτουν στις CFLAGS τους το -fPIC, έπαιρναν τέτοια μηνύματα. Δεν γίνεται λοιπόν να βάλει κάποιος άιντε χύμα στην CFLAGS το fPIC ή το fPIE και τελείωσε. Ο τρόπος που υλοποιείται από τις διανομές είναι μέσω του spec του compiler το οποίο έχει μέσα δομές if οι οποίες του λένε "θέλει ο χρήστης PIC" -> Αν ναι, δες για τι object μιλάμε -> Είναι βιβλιοθήκη ; Τότε PIC αλλιώς PIE.

Αυτό ιστορικά - εγκυκλοπαιδικά.

Τώρα όσον αφορά το configure, το PIE δεν είναι επιλογή του configure αλλά του compiler για αυτό δεν το βρίσκεις. Στο τερματικό που πας να χτίσεις το πρόγραμμα, πριν τρέξεις το configure, δες τι τιμή έχουν οι μεταβλητές CFLAGS, CXXFLAGS. Λλογικά δεν πρέπει να έχουν τιμή αλλά αν έχουν μέσα το fPIC βγάλε το. Αλλιώς μπορείς πριν τρέξεις το configure να τρέξεις export CFLAGS="-O2 -pipe -fPIC -fPIE" και το ίδιο στο CXXFLAGS και να τρέξεις μετά το configure να δεις αν λειτουργεί. Πάνε χρόνια από τότε που ήταν κοινό πρόβλημα και δεν πολύ θυμάμαι αλλά έχω την εντύπωση ότι όταν έδινες μόνο το PIE (ή και τα δύο), επέλεγε το σωστό ανάλογα την περίπτωση. Πιθανώς να μην λειτουργήσει αλλά και πάλι δεν θα έπρεπε καν να υπάρχει το παραπάνω πρόβλημα (ειδικά σήμερα).

Δεν γνωρίζω από ubuntu οπότε ίσως κάποιος άλλος να δώσει πιο σωστές πληροφορίες.

τελικά το έκανα εγκατάσταση με το έτοιμο deb πακέτο γιατί δεν έβγαζα άκρη. Το παράξενο πάντως είναι ότι μέχρι και πριν κάνω το upgrade στην τελευταία lts έκδοση χτιζόταν μια χαρά με κάθε git pull που έκανα χωρίς κάποιο πρόβλημα και το συγκεκριμένο. 

[imitheos]

1 ώρα πριν, Linuxdudemeban είπε

να σου πω επειδή διαβάζω καιρό τώρα τα post σου, μια προτροπή, βγάλε το ημι (imi) από το nickname σου

Το συγκεκριμένο ποστ μου δεν ήταν καθόλου καλό. Εξήγησα με δύο λέξεις και εντελώς μπακάλικα τι είναι το PIC αντί να το εξηγήσω σωστά. Απλά δεν ήθελα να μακρυγορήσω με το θεωρητικό κομμάτι  που μπορεί να μην νοιάζει καν τον check2fire και απλά να ζητάει μια λύση.  Ήδη η συμβουλή μου (στην οποία κάτι δεν μου αρέσει αλλά δεν θυμάμαι τι για αυτό είπα ότι πιθανώς να μην λειτουργήσει) είναι μικρότερη σε όγκο από το ιστορικό κομμάτι.

Ευχαριστώ πάντως για τα καλά σου λόγια.

10 λεπτά πριν, chek2fire είπε

τελικά το έκανα εγκατάσταση με το έτοιμο deb πακέτο γιατί δεν έβγαζα άκρη. Το παράξενο πάντως είναι ότι μέχρι και πριν κάνω το upgrade στην τελευταία lts έκδοση χτιζόταν μια χαρά με κάθε git pull που έκανα χωρίς κάποιο πρόβλημα και το συγκεκριμένο. 

Να σου πω ένα παράδειγμα από άλλη διανομή. Το rpm υποστηρίζει χιλιάδες macros που διέπουν το χτίσιμο και επιτρέπουν με μία εντολή να χτίζεις πακέτα. Με το ίδιο spec και την ίδια εντολή (πχ rpmbuild -bb bitcoind.spec) θα έχεις άλλο αποτέλεσμα σε fedora και άλλο σε opensuse. Ακόμη και στην ίδια διανομή μπορεί να αλλάξει κάτι. Στο Tumbleweed πριν 5-10 ημέρες αλλάξε το macro του "libexec" καταλόγου από lib ξανά σε libexec. Έτσι αν έχτιζες με την ίδια ακριβώς εντολή το ίδιο πρόγραμμα δύο φορές σε δύο ημέρες, την τρίτη θα είχες αρχεία μόνο στο /usr/lib και την τετάρτη θα είχες και στο /usr/libexec. Κάποια άλλη στιγμή ενεργοποιήθηκε globally το LTO οπότε ξαφνικά μπορεί το πρόγραμμα που πήγαινες να κάνεις compile από την μία ημέρα στην άλλη να μην γίνεται compile (επειδή κάποιος κώδικάς του έχει γραφτεί έτσι που δεν παίζει με LTO).

Δεν ξέρω / θυμάμαι πώς λειτουργεί το build system του debian / ubuntu (ούτε και τα βήματα που ακολούθησες για να το χτίσεις) για αυτό δεν μπορούσα να σου πω με ακρίβεια τι φταίει. Μπορεί για παράδειγμα στη νέα έκδοση του ubuntu να άλλαξαν κάποιες παραμέτρους στο χτίσιμο και αυτές να αποθηκεύτηκαν σε κάποιο .la αρχείο οπότε να  "τραβάει" το -fPIC  στο δικό σου χτίσιμο.

 

Επεξ/σία 22 Μαΐου 2020 από imitheos