Hur ersätta libbar i Linux

[TomasL]

Försöker kompilera några program, problemet är att ur programmets synpunkt så är några libbar felkompilerade, så jag måste kompilera om dem.
Några libbar är för gamla, vad det verkar, så de behöver bytas ut.

Nåväl, kompilera libbarna med rätt argument, och installerar dem, inkluderar foldern där de hamnar i ldconf.conf, och kör ldconf.
Lik förb så hittar inte mitt program de nya libbarna, inte ens om jag inkluderar sökvägen till dem som argument till ./configure.

Tanken är att göra en statisk länkning så jag slipper helsiket med libbar i framtiden.

Libbarna det handlar om är wxGTK (installerad rätt version, men vissa erforderliga funktioner är inte in-kompilerade) och zlib (fel version).

[sodjan]

Jag vet inte så mycket specifikt om Linux, men jag antar att det som
vanligt vore väldigt användbart med lite info om miljö och verktyg.
OS? Kompilator? Kanske ett litet test-case med kommandoraden och
faktiskt resultat o.s.v.

> Lik förb så hittar inte mitt program de nya libbarna,

Är det inte kompilator och/eller länkare som ska hitta "libbarna"?
Inte ditt program?

> Tanken är att göra en statisk länkning så jag slipper helsiket med libbar i framtiden.

"Libbar" är det väl i alla fall, bara statiskt länkade istället för dynamiskt.

Har länkare (och/eller kompilator) några fördefinierade sökvägar?

Här verkar samma eller i alla fall en liknande frågeställning diskuteras:
http://stackoverflow.com/questions/2915 ... the-linker

[lillahuset]

Det TomasL har råkat ut för är pingvinens svar på "DLL hell".

[sodjan]

Nej, det skulle jag inte säga. Det verkar mer vara lite problem
kring hur man länkar statiskt mot bibliotek. Sen så är dynamiska
och statiska bibliotek sannolikt (ganska säkert) olika, och man kan
nog inne länka statiskt mot dynamiska bibliotek, eller tvärtom.

"DLL hell" har specifikt med dynamiskt laddade bibliotek att göra.
Och det berör så klart vilken miljö som helst som stöder dynamiska
bibliotek, inte enbart där filerna heter just ".DLL". Däremot verkar ju
önskan från Tomas att länka statiskt vara för att undvika just det.

Men det saknas en hel del info för att kunna säga mer om det. Men
sannolikt har det med att göra hur biblioteken ska definieras till länkaren.

[lillahuset]

Jo TomasL hade råkat ut för det och vill undvika det i framtiden och vill alltså länka statiskt. Vilket är en utmärkt idé. Så uppfattade jag det iallafall.

Som jag minns det var det inga konstigheter att använda zlib men jag kanske bara hade tur.
Här har du zlibbar: http://zlib.net/ Men det hade du antagligen redan upptäckt.

wxGTK har jag ingen erfarenhet av.

[TomasL]

Jo, jag vill undvika "DLL-Helvetet" sas, och därför länka statiskt, det är den ena saken.
Mitt problem är att configure inte tycker att libbarna finns, oavsett om jag installerar dem med ldconfig, eller anger sökvägen till libbarna till configure-scriptet.

Saken är ju att jag inte kan avinstallera de gamla libbarna, pga andra beroenden.

Om jag till exempel bygger wxGTK, och gör en "make install" så hamnar dessa, per tradition, om jag fattat det rätt, i /usr/local/lib, då ger jag /usr/local/lib som argument till configure för mitt program, men det skiter sig, enligt configure så är det fel lib, men configure tror av någon anledning att det är orginallibbet som skall användas, inte mitt nykompilerade.

[Jan Almqvist]

Det TomasL har råkat ut för är pingvinens svar på "DLL hell".

I Windows finns nu även alternativet "Manifest hell".

[Nerre]

Är det inte så enkelt att du behöver låta din källkod peka på header-filerna till de "statiska" libbarna?

I nuläget pekar de kanske på header-filerna för de dynamiska?

[TomasL]

Nu är det iofs inte mitt program, per se, utan ett jag hämtat hem.
Men enligt instruktion skall man i till ./configure ange argumenten --static för att få en statisk länkning till exempel.
Nu har jag gjort exakt detta, med samma program för typ 4 år sedan eller så, och hade säkert samma problem då, men jag kan inte komma på hur jag gjorde.
Naturligtvis så har jag ingen kopia kvar, då det försvann när min gamla mediaserver skruvade till sig.

[Glenn]

Fast att ange --static gör ju antagligen bara att de libbar du pekar på länkas in statiskt, i.e inte behöver laddas dynamiskt vid körning, om du inte lyckas peka ut libbarna vid kompilering så kommer du ju aldrig så långt att --static gör någon skillnad.

Just att peka ut en viss version av libbar att länka med under kompilering var ju något man ofta fick bråka med förr (bland annat av det skälet som TomasL nämner tidigare, att man har flera versioner som konfliktar) , exakt hur det görs med configure beror ju lite på mjukvaran i fråga dock.

[sodjan]

> I nuläget pekar de kanske på header-filerna för de dynamiska?

Hm, header filerna innehåller deklarationer för funktioner som
man vill anropa. Om vi antar att funktionerna has samma namn
och samma argument i båda fallen oavsett om man länkar
dynamiskt eller statiskt, så ser jag inte hur det har någon
betydelse vilken header fil man använder.

Valet av bibliotek (och om de är dynamiska eller statiska) görs ju
senare, under länkningen, inte vid kompileringen (d.v.s. då header
filerna läses in).

Så fungerar det i alla fall normalt...

Men varför skulle det vara olika header filer?

> oavsett om jag installerar dem med ldconfig,

Men ldconfig är väl specifikt för att "installera" dynamiska bibliotek (?).
Jag ser inte att det har något med länkning statiskt att göra.

[henkebenke]

Kan du inte skicka med en library-path till configure?

Kod: Markera allt

./configure -L /pathen/till/dina/fungerande/lib

[TomasL]

Jo det är ju det jag gör, men det funkar tydligen inte.

[TomasL]

Men ldconfig är väl specifikt för att "installera" dynamiska bibliotek (?).
Jag ser inte att det har något med länkning statiskt att göra.

Naturligtvis är det så, vad jag menar är att om jag installerar libbarna med ldconfig, så hjälper det inte, när jag försöker kompilera med dynamiskt länkade libbar.

[sodjan]

Ah, så det är problem i båda fallen alltså, det ger
ju en lite annorlunda felbild... I'm out...