[RH null] GCC 3.2 probleempje

[Verwijderd]

Ik heb een programma, dit programma noem ik nu maar even programma 'A'.
Dit programma bestaat uit een executable en een shared object library.
A heb ik geschreven en steeds gecompileerd onder Red Hat 7.3 (GCC 2.96)

Nu ben ik overgestapt op Red Hat Null (beta3 van RH8) en probeer A maar weer eens te compileren, maar deze keer met GCC 3.2 (die bij NULL zit)

Na een hoop unresolved externe functies te hebben opgelost zit ik er nu nog met 1 waarvan ik echt NIET weet wat ik er mee aan moet
Zie de output van ldd van de so:

libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
libm.so.6 => /lib/i686/libm.so.6 (0x4015d000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x40180000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0x401f3000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4026f000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40283000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40291000)
libdl.so.2 => /lib/libdl.so.2 (0x4036f000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40372000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40424000)
undefined symbol: __dso_handle (./libA.so)

En dit is wat ik te zien krijg wanneer ik m'n programma probeer te starten:

./A: relocation error: /<pad>/libAditIsDieLibraryDieWordtGebruiktDoorA.so: undefined symbol: __dso_handle

Met het nm commando kon ik zien dat deze __dso_handle in libgcc_s.so zat:

nm /usr/lib/libgcc_s.so | grep __dso_handle
00007000 d __dso_handle

Maar libgcc_s is dus al gelinkt met dat programma + bijbehorende library..

Weet iemand misschien hoe ik dit kan oplossen?
(ik zit al sinds vanochtend vroeg te prutsen hiermee terwijl ik normaal altijd alles in een paar minuutjes heb opgelost.. )

Volgens G00gle heeft het allemaal te maken met GCC 3.2, en verder wordt ik daar ook niet echt veel wijzer van, want dat had ik zelf ook wel kunnen bedenken dat het komt door deze nieuwe versie van de compiler + bijbehorende zut.

Oja, ik heb ook al bijna alle mogelijke (toepasbare) link opties geprobeerd, waaronder -shared en -fPIC

[Wilke]

Je hebt zowel library als programma opnieuw gecompileerd met GCC 3.2? Zijn *alle* libraries in het systeem met GCC 3.2 gecompileerd?

Het lijkt er namelijk op dat een van de libs nog in het oude formaat is en dat je daardoor die fouten krijgt.

[Verwijderd]

Je moet de library opnieuw met gcc-3.2 compileren. Binaries van gcc-2.96, 2.95 en 3.x zijn niet interoperable.

edit:
Wilke, ga eens achterin je stoel zitten jij, je bent steeds eerder! .

[Verwijderd]

Alles is helemaal gecompileerd met GCC 3.2 van RH null dus dat kan het (helaas) niet wezen..

[Verwijderd]

Hm, zou het niet aan die optimalisatie zut kunnen liggen? (staat nu op standje O2)

/me is nu bezig met hercompileren op O1 (weer 10 minuten wachten )

edit:
Nee, helpt ook niet..

[Verwijderd]

Aangezien je c++ gebruikt, is je g++ compiler dezelfde versie als de gcc? Zijn alle libraries (libdc_++, glibc) uptodate?

[Verwijderd]

GCC en G++ zijn allebei dezelfde versie en alle libs zijn aardig up-to-date..

Ik heb net een heleboel zitten lezen op mailinglists enzo (gcc.gnu.org) en het begint er steeds meer op te lijken dat ik nieuwere binutils erop moet zetten en dat dit probleem komt door een of andere 'hidden' optie in een van die tools (die er nog niet in zat met 2.x)

Downgraden naar een versie die die optie niet heeft zou ook moeten kunnen maar ik zou eigenlijk niet weten of dat wel kan dus ik ga maar voor de wat veiligere weg en download nu de allernieuwste versie......

_{ik had ook kunnen weten dat het niet helemaal goed zou kunnen gaan met een beta (null)}

[Verwijderd]

Heb nu binutils 2.12 (die van null is 2.13) erop staan, maar nu krijg ik voor iedere library zo'n zelfde undefined symbol error ipv alleen m'n eigen lib

[Wilke]

Ja, nu moet je dus ws eerst al die andere libs opnieuw compileren - fijn he!

Hey, als je zelf zo aan het pielen bent met Linux is Gentoo dan niet iets voor jou? Die zou dit namelijk automatisch kunnen - alles hercompileren met een nieuwere gcc en binutils.

Het compileren duurt dan nog steeds lang maar je zit in ieder geval niet met dit soort gedonder...onder Slackware denk ik ook wel 10x na voor ik ook maar naar glibc wijs, laat staan dat ik zomaar even upgrade naar GCC 3.2.

offtopic:
Ik heb als newbie eens de werkende /lib/libc5.x.so gedelete.

Dan doet je Linux systeempje op slag vrij weinig meer kan ik je verzekeren Ook de standaard windows-oplossing 'gewoon rebooten' haalt dan verrekte weinig uit

[Verwijderd]

Wilke schreef op 19 september 2002 @ 22:11:
Ja, nu moet je dus ws eerst al die andere libs opnieuw compileren - fijn he!

Weet et.. maar het werkt allemaal neit

Hey, als je zelf zo aan het pielen bent met Linux is Gentoo dan niet iets voor jou? Die zou dit namelijk automatisch kunnen - alles hercompileren met een nieuwere gcc en binutils.

Het compileren duurt dan nog steeds lang maar je zit in ieder geval niet met dit soort gedonder...onder Slackware denk ik ook wel 10x na voor ik ook maar naar glibc wijs, laat staan dat ik zomaar even upgrade naar GCC 3.2.

Probleem is dat ik daar geen tijd voor heb..

offtopic:
Ik heb als newbie eens de werkende /lib/libc5.x.so gedelete.

Dan doet je Linux systeempje op slag vrij weinig meer kan ik je verzekeren Ook de standaard windows-oplossing 'gewoon rebooten' haalt dan verrekte weinig uit

/me wist gelukkig al wat libc was toen ie Linux n00b was

[Wilke]

[b][message=15229883,noline]
* Wilke wist gelukkig al wat libc was toen ie Linux n00b was

Ja...ik ook en dan NOG zoiets doen dus....

Probeerde libc te vervangen op de uhmmmm 'minder slimme manier' zeg maar

Maar goed, jij hebt nu dus een beetje een verkloot systeem (qua libraries) - misschien is het handiger om, als je geen tijd over hebt, gewoon een stabiele distro te houden tot er gewoon GCC 3.x-distro's te krijgen zijn? Anders is Gentoo echt de enige handige keus momenteel (ze zijn pioniers op het GCC 3.2 gebied volgens mij...correct me if I'm wrong)

[Verwijderd]

Wilke schreef op 19 september 2002 @ 22:49:
Maar goed, jij hebt nu dus een beetje een verkloot systeem (qua libraries) -

Ik maak altijd backups

misschien is het handiger om, als je geen tijd over hebt, gewoon een stabiele distro te houden tot er gewoon GCC 3.x-distro's te krijgen zijn? Anders is Gentoo echt de enige handige keus momenteel (ze zijn pioniers op het GCC 3.2 gebied volgens mij...correct me if I'm wrong)

Tja, maar ik heb deze juist genomen omdat ik GNOME2 zo mooi vind en ik heb geen vrije ruimte meer over op m'n 80 Gb grote HD
En Gentoo duurt me toch ff te lang..

[Verwijderd]

Een domme opmerking mischien, maar je hoeft toch alleen op te letten (lees: alles te hercompileren) met C++ libs als je van compiler wisselt?

[Verwijderd]

Binutils (assembler, linker, etc) worden samen met de compiler gebruikt dus je moet idd wat dingen hercompileren..

Maar.. ik heb nog wat verder gezocht, en in het bestandje crtbegin.asm zou het volgende staan:

#hoopassemblyzut
..
#ifdef HAVE_GAS_HIDDEN
.hidden __dso_handle
#endif

En als het goed is is dit het gedeelte wat niet goed werkt, waardoor __dso_handle helemaal niet in de uiteindelijke (dynamische) library terecht komt.

Het zou moeten werken door een commentaar dingetje voor HAVE_GAS_HIDDEN te zetten in een van de config headers zodat deze buggy 'feature' niet wordt gebruikt.

Nou, ik ga nu eerst eens proberen om van m'n eigen library een statische library te maken (ik zou dan geen last van deze bug moeten hebben)
Als dat niet werkt moet ik de 2 extra source rpm cd's gaan downloaden en bakken en het bovenstaande wijzigen + wat zut hercompileren....

Sigh.. beta's..

edit:

Kheb er nu een statische library van gemaakt en nu werkt het wel, eindelijk!
..al heb ik nu wel een executable van zo'n 12 Mb

Nu nog ff proberen die .hidden feature 'uit' te zetten..