[C++] undefined reference to `__clzsi2' bij crosscompileren

[cyberstalker]

Ik probeer par2cmdline te cross-compileren voor een embedded MIPS apparaat, ik krijg de linker echter niet zover dat deze de referentie naar __clzsi2 kan vinden. De exacte fout die ik krijg is het volgende:

mainpacket.cpp:(.text._ZSt4__lgi[std::__lg(int)]+0x20): undefined reference to `__clzsi2'

Ik heb al gegrept naar bibliotheken die deze functie implementeren, en het lijkt erop dat deze functie wel bestaat. Het volgende command en de uitvoer toont dit, wanneer ik het uitvoer in de map met de toolchain:

code:

$ grep -r "__clzsi2" /usr/src/freetz/toolchain/target/lib
Binair bestand /usr/src/freetz/toolchain/target/lib/gcc/mips-linux-uclibc/4.5.3/libgcc_pic.a bevat de gezochte tekst.
Binair bestand /usr/src/freetz/toolchain/target/lib/gcc/mips-linux-uclibc/4.5.3/libgcc.a bevat de gezochte tekst.
Binair bestand /usr/src/freetz/toolchain/target/lib/libc.so.0 bevat de gezochte tekst.
Binair bestand /usr/src/freetz/toolchain/target/lib/libuClibc-0.9.32.1.so bevat de gezochte tekst.
Binair bestand /usr/src/freetz/toolchain/target/lib/libgcc_s_pic.a bevat de gezochte tekst.

Nu heb ik al geprobeerd met -l deze library te gebruiken, maar tot nog toe zonder resultaat.

code:

mips-elf-g++ -Wall -L/usr/src/freetz/toolchain/target/lib/ -luClibc-0.9.32.1 par2cmdline.o commandline.o crc.o creatorpacket.o criticalpacket.o datablock.o descriptionpacket.o diskfile.o filechecksummer.o galois.o mainpacket.o md5.o par1fileformat.o par1repairer.o par1repairersourcefile.o par2creator.o par2creatorsourcefile.o par2fileformat.o par2repairer.o par2repairersourcefile.o recoverypacket.o reedsolomon.o verificationhashtable.o verificationpacket.o -lstdc++ -o par2
mainpacket.o: In function `std::__lg(int)':
mainpacket.cpp:(.text._ZSt4__lgi[std::__lg(int)]+0x20): undefined reference to `__clzsi2'
collect2: ld returned 1 exit status

Als ik met google zoek kom ik enkel mensen tegen die dit probleem met Android-ndk hebben, waarbij deze mensen het hebben kunnen oplossen door expliciet naar libgcc te linken. Dit werkt bij mij ook niet. Hoe kan ik dit toch gelinkt krijgen?

[Soultaker]

Meestal zitten dit soort functies in libgcc, en wordt die standaard (statisch) meegelinkt. Maar ik zie dat je ook al handmatig linkt tegen uClibc en libstdc++, zonder dat je -nodefaultlibs specificeert. Dat is raar. Ik hoef nooit dit handmatig deze libraries mee te geven als ik crosscompile.

Anyhow, kun je eens controleren of die uClibc library die symbol bevat? Bijvoorbeeld zo:

mips-elf-objdump -t /usr/src/freetz/toolchain/target/lib/libuClibc-0.9.32.1.so | grep __clzsi2

Dat de string in de binary voorkomt zegt op zichzelf natuurlijk niet dat die functie ook in die library gedefinieerd wordt.

Verder verwachten linkers dat libraries na de objects die ze nodig hebben op de command line geplaatst worden. Verplaats die -luClibc dus eens naar het einde van de regel. Als 'ie dan nog niet gevonden wordt, kun je libgcc nog toevoegen. Je zegt dat "dit ook niet werkt"; waarom niet? Hoe ziet je command line er dan uit, en wat voor foutmelding krijg je?

[ Voor 6% gewijzigd door Soultaker op 24-05-2012 21:05 ]

[cyberstalker]

Ik kende het objdump commando nog niet, maar je hebt gelijk dat de symbol niet in de uClibc library staat. Ik heb dat commando ook uitgevoerd op alle .so bestanden in de toolchain, en geen van de libraries blijkt dat symbol te hebben. Wat ik dan wel weer vreemd vind is dat er dus .so bestanden zijn die naar een symbol verwijzen, terwijl niemand het heeft.

Ik heb ook, zoals je voorsteld de libraries na de objects gezet, dit heeft (uiteraard) geen resultaat, omdat het symbol ook niet in die library staat. libgcc heeft het symbol ook niet (volgens objdump).

Betekent dit nu dat mijn toolchain incompleet/kapot is?

[Soultaker]

Mogelijk, of dat libstdc++ met een andere toolchain gecompileerd is. Maar ik vermoed toch dat 'ie wel ergens is. Post de hele uitvoer van objdump -t libgcc.a eens ergens (niet hier, maar op pastebin ofzo)?

Oh, en wat gebeurt er je al die libraries (alle -L en -l opties) weghaalt? Die zou je namelijk helemaal niet nodig moeten hebben.

[ Voor 23% gewijzigd door Soultaker op 24-05-2012 21:35 ]

[Zoijar]

Klinkt als andere name mangling, i.e. andere C++ compiler (versie). Die zijn iha niet link compatible.

[Soultaker]

Alleen is __clzsi2 een gcc library function; geen C++ functie. Hij is dus helemaal niet mangled als het goed is.

[cyberstalker]

Met alle library opties weggehaald werkt het ook niet. De Makefile die bij par2cmdline wordt gegenereerd door ./configure had zelf eerst alleen de -lstdc++ in het commando staan, als ik dat weghaal blijft het probleem hetzelfde.

De complete symbol table staat nu op http://pastebin.com/fG2Gg0b0 .

Wat ik zelf opmerkelijk vind is dat de functie __clzdi2 er *wel* instaat, maar dat de __clzsi2 in geen velden of wegen te bekennen is.

[Soultaker]

Da's vreemd inderdaad. Hoe kom je aan die toolchain? Heb je die zelf gecompileerd? Anders misschien eens recompilen zodat je zeker weet dat libstdc++ met de juiste versie gecompileerd is?

[ Voor 39% gewijzigd door Soultaker op 25-05-2012 17:29 ]

[farlane]

Soultaker schreef op donderdag 24 mei 2012 @ 22:03:
Alleen is __clzsi2 een gcc library function; geen C++ functie. Hij is dus helemaal niet mangled als het goed is.

De poster gebruikt ulibc, dus het kan zijn dat deze die functie niet implementeert.

[Soultaker]

GCC hoort die functies te implementeren; niet de C library. Daar is libgcc voor.

Het zijn geen C library functies; het zijn functies die de compiler verzonnen heeft om niet te veel inline code te genereren voor complexe operaties waar de target processor geen native support voor heeft.

[farlane]

Soultaker schreef op vrijdag 25 mei 2012 @ 18:51:
GCC hoort die functies te implementeren; niet de C library. Daar is libgcc voor.

Ah ja, daar heb je natuurlijk gelijk in, maar dan heeft je objdump op ulibc.so ook niet zoveel zin toch?

@TS Misschien is er met de MIPS versie van deze toolchain iets aan de hand? Heb je evt een andere versie waarmee je kunt testen?

[edit]
Kan ook zijn dattie een verkeerde versie van de gcc lib pakt (multilib). Is je -march wel goed?

[ Voor 11% gewijzigd door farlane op 25-05-2012 23:15 ]