[C++] glibc linking problem

[Memorice]

Ik heb een probleem met het compilen van een SDK, waarvan ik deels alleen de shared object (.so) bestanden heb. Het probleem is dat ik deze SDK wil compilen op een debian distributie met een enigzins verouderde kernel (2.6.32-5-amd64). Dit zorgt er voor dat een aantal vereiste libraries niet voldoende up-to-date zijn.

Helaas is het geen optie om te upgraden naar een nieuwere kernel noch is het een optie om een ander systeem te zoeken voor het compilen. Dit wegens het feit dat het desbetreffende systeem een groot computer cluster is en de SDK onderdeel is van code dat nogal CPU intensief is. Wel kan ik melden dat de SDK zonder problemen compiled op een up-to-date Ubuntu systeem.

Gelukkig is dit voor de meeste libraries geen al te groot probleem, door ze simpelweg aan te bieden in LD_LIBRARY_PATH. Echter zorgt GLIBC (versie 2.11) voor problemen, omdat deze versie kennelijk niet backwards compatible is met de gebruikte kernel, ondanks het feit dat ik de configure flag --enable-kernel=2.6.18 gebruik bij het compilen van GLIBC. Wanneer ik andere versies specificeer krijg ik overigens de boodschap dat de kernel te oud is, zelfs voor toekomstige kernel versies...

GLIBC 2.11 compileerd zonder problemen, maar wanneer ik hier naar verwijs in LD_LIBRARY_PATH zorgt dit voor segmentation faults bij simpele shell commands zoals 'ls'. Als gevolg hiervan zit ik momenteel een beetje vast met het zoeken naar een oplossing voor dit probleem, dus ik hoop eigenlijk dat jullie nog ideeen hebben.

Een aantal andere mogelijkheden die ik al heb overwogen zijn:
- Maak een executable zonder dynamic linking, i.e. static linking. Het probleem hiervan is dat de benodigde .a bestanden van de SDK niet aanwezig zijn en tevens ontbreekt de source om deze te maken.
- Decompile/disassemble de .so bestanden om er vervolgens .a bestanden van te maken. Het probleem hiervan is dat dit expliciet verboden is in een aantal getekende contracten. Tevens is het me onduidelijk of dit een realistische mogelijkheid is en hoe dit precies in z'n werk gaat, gezien veel zoeken hier geen uitsluitsel over geeft.
- De eigenaar van de SDK vragen om van static libraries te voorzien. Dit is wegens bepaalde omstandigheden, waar ik hier op het forum niet dieper op in wil gaan, helaas ook geen realistische mogelijkheid.

[igmar]

Wat is exact je probleem ? glibc staat los van je kernel, op het feit na dat glibc syscalls aanroept. Die syscalls verschillen echter niet per kernel release (op toevoegingen na). Misschien moet je je verhaal eens onderbouwen met een concrete melding oid, want ik zie het verband niet tussen userspace libs en een bepaalde kernel versie.

[johnkeates]

Wat dacht je van een toolchain/buildenv opzetten waarbij je lekker naar andere versies kan verwijzen? Dan hoef je je eigen systeem niet aan te passen en kan je gewoon binnen die eisen blijven werken.

[hostname]

Als je alleen de shared objects heb, wat wil je dan compilen? Daarvoor heb je de source nodig.

Bovendien, waarom ga je zelf glibc compileren? Waarom voldoet de standaard glibc van Debian niet? Debian komt standaard ook al met glibc 2.11.2.

[Memorice]

@igmar
Het probleem is dat wanneer ik naar de nieuwe GLIBC verwijs in LD_LIBRARY_PATH dat dan een hele hoop shell commands (zoals 'ls') segmentation faults opleveren. Ik weet niet wat ik hier nog meer aan zou moeten onderbouwen?

@johnkeates
Misschien lost dit het build probleem op, om eerlijk te zijn heb ik hier geen ervaring mee, maar zal me er eens in verdiepen. Wel vraag ik me af of ik dan niet hetzelfde probleem heb wanneer ik de code wil runnen?

@hostname
De huidige GLIBC versie die in deze debian installatie zit is versie 2.7 en dat is dus niet toereikend. De reden voro het compilen is dat ik deels de .so bestanden heb, maar dat een deel van de SDK ook gewoon source bestanden zijn.

[hostname]

Memorice schreef op vrijdag 12 augustus 2011 @ 16:39:
@hostname
De huidige GLIBC versie die in deze debian installatie zit is versie 2.7 en dat is dus niet toereikend. De reden voro het compilen is dat ik deels de .so bestanden heb, maar dat een deel van de SDK ook gewoon source bestanden zijn.

Welke Debian versie draai je dan? 2.6.32-5-amd64 is de kernel van 6.0 "Squeeze", en die heeft gewoon glibc 2.11.2. 5.0 "Lenny" heeft nog glibc 2.7, maar die heeft ook een oudere kernel (2.6.26). Dus het lijkt erop dat je een mix van verschillende versies draait, wat over het algemeen het ideale recept voor problemen is. Welke versie is het nu eigenlijk echt? (cat /etc/debian_version)

Verder neem ik aan dat je glibc opnieuw aan het compileren bent omdat je SDK een nieuwere glibc nodig heeft?

[Memorice]

Het is idd squeeze en cat /etc/debian_version levert '5.0.8' op. En het is toch echt libc-2.7.so dat in de /lib/ directory zit, strings /lib/libc-2.7.so | grep GLIBC levert dit op:

GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_PRIVATE

En ja ik ben GLIBC opnieuw aan het compilen om dat m'n library een nieuwere versie nodig heeft.

[hostname]

Je hebt geen Squeeze maar een Lenny installatie met de Squeeze kernel (en waarschijnlijk ook de udev en een aantal aanverwante componenten). Het beste kan je gewoon helemaal upgraden naar Squeeze; Lenny is inmiddels inderdaad bijna antiek en security support eindigt over een krap half jaar. Je zou ook de libc packages uit Squeeze kunnen installeren en kijken of het dan werkt, dan zou je libc 2.11 moeten hebben (met als risico dat het nog meer incompatible is geworden en helemaal niet meer werkt). Als je dat niet kan doen dan zou ik idd de tip van johnkeates opvolgen en een eigen toolchain/buildenv opzetten.

[ Voor 20% gewijzigd door hostname op 12-08-2011 17:43 ]

[Memorice]

Misschien heb je m'n openings post niet helemaal gelezen, maar het gaat hier om een groot computer cluster, waar ik dus geen admin rechten op heb. Dus upgraden is sowieso geen optie.

[Soultaker]

Memorice schreef op vrijdag 12 augustus 2011 @ 06:53:
Ik heb een probleem met het compilen van een SDK, waarvan ik deels alleen de shared object (.so) bestanden heb. Het probleem is dat ik deze SDK wil compilen op een debian distributie met een enigzins verouderde kernel (2.6.32-5-amd64). Dit zorgt er voor dat een aantal vereiste libraries niet voldoende up-to-date zijn.

Wat gaat er dan misschien mis?

Ik zou denken dat je meer succes hebt met het patchen van je SDK zodat 'ie op de oude distro werkt, dan dat je een hele aparte libc installeert. Dat is vragen om problemen, zeker als de kernel die je draait eigenlijk unsupported is.

[Memorice]

@Soultaker
Wat bedoel je met je vraag wat er misschien mis gaat?

En legaal gezien mag ik geen wijzigingen aanbrengen in die SDK, dit kan dus problemen opleveren wanneer wij onze code moeten opleveren aan onze opdracht gever. Dus dit is enigzins ongewenst.