ldconfig probleem (?)

[jb044]

Had deze vraag ook al op usenet gesteld, maar vrees dat dat medium tenminste waar het ooit voor bedoeld was behoorlijk dood is

Zal jullie maar niet met al te veel details vermoeien, maar ter
inleiding dit zijn zo'n beetje de randvoorwaarden:

Ik moest weer eens zo nodig in Kodi rondklikken en zag wat vreemd
ontbrekende opties. Wel kunnen rippen naar aac en wma en niet naar FOSS
approved formaten in een mooi stukje opensource software durf ik vreemd
te noemen tenminste! Kennelijk hebben ze de nodige functionaliteit
verplaatst naar optionele binary addons. En ja ik heb natuurlijk weer
een CentOS 7 based HTPC annex hobby-server systeempje dus dan mag je dat
soort dingen mooi zelf oplossen. Afijn vele uren later heb ik een
werkende rpm, alleen 1 maar:

kodi 16.1-2 requires libmodplug.so.0 (64-bit)

Die was er idd niet, wel een libmodplug.so.1 symlink en een
libmodplug.so.1.0.0 file in /usr/lib64

Dan symlinken we m toch zelf, nope
Dan bouwen we libmodplug toch zelf met een embedded libmodplug.so.0
symlink, nope

Wat ik ook probeer ldconfig pikt de .0 symlink gewoon niet op! rpm -q
--whatprovides /usr/lib64/libmodplug.so.0 levert alleen wel keurig
libmodplug op, dus rpm technisch is ie aanwezig!?

Als ik er iets van moet zeggen is het dat het me niks zou verbazen dat
puur de aanwezigheid van de libmodplug.so.1 het 'probleem' is, o ja en
dat "grep -r libmodplug" in de kodi source tree niets opleverde dat ik
simpelweg daar kon fixen

Wie weet meer?

Voor nu doe ik voor de zekerheid maar een
LD_PRELOAD=/usr/lib64/libmodplug.so.0 voor mijn kodi commando. Ben er
vrij zeker van dat dit alles een obscuur detail is, maar ik zit niet op
(nog meer) crashes van Kodi te wachten natuurlijk.

[Thralas]

Volgens mij ben je nu vooral bezig met het zoeken naar een ranzige workaround, terwijl je die tijd beter kunt steken in het oplossen van je werkelijke probleem.

Die library suffixes zijn er niet voor de lol, maar om ABI incompatibilities te managen. Daarnaast staat de SONAME ook in de ELF headers, wat zou kunnen verklaren waarom je 'workaround' ook niet werkt.

Waarom stel je je niet de vraag waarom je Kodi (klaarblijkelijk) gelinkt is tegen een versie van libmodplug die jij niet hebt? Probeer dat probleem op te lossen.

Waar heb je Kodi vandaan? En libmodplug? Die laatste zit in EPEL, dus dan zou ik Kodi vervangen voor een versie die daar wel bij past.

[jb044]

Kodi is gecompileerd (met rpmbuild) op basis van de officiële ongepatchte sources.

Maar je hebt een punt ik weet te weinig van de werking van dynamische libraries in Linux om dit goed op te kunnen lossen Het viel me bv op dat zelfs als ik de libmodplug.so.1 symlink verwijder, ldconfig m zelf weer aanmaakt. Dat heeft zeker te maken met hetgeen jij beschrijft? Punt is dat vlc en zoneminder ook afhankelijk zijn van libmodplug, en wel de versie met de .1 so symlink, vlc kan ik zonder maar zoneminder vind ik toch wel fijn...

Het probleem ontstaat vanuit de binary addons van Kodi, zonder die expliciet mee te nemen heb ik dit probleem niet en nooit gehad. En de reden dat ik die addons wil is eigenlijk alleen om de auto-rip functie van Kodi van audio cd's imho goed te krijgen. Naar flac dus en niet alleen naar wma of aac. Wellicht een addon uitschakelen, nog mooier is om het probleem, zoals jij ook al zegt, daadwerkelijk op te kunnen lossen Als het even kan zonder deze build, die toch vooral heel persoonlijk is en ook voor experimenten wordt gebruikt nog verder te vernaggelen.

[Hero of Time]

Wat weerhoud je er eigenlijk van om CentOS 7, wat toch wel redelijk outdated software bevat, te verruilen voor een wat nieuwere distro? Ubuntu 16.04 is bijvoorbeeld een recente release en kan zonder enige problemen Kodi aan en alles wat je er nog meer op wil draaien. Vind je Ubuntu niks, of twijfel je, dan kan je altijd nog Debian Jessie (huidige Stable) nemen. Die is recenter dan CentOS, maar wat meer uitontwikkeld dan Ubuntu 16.04 en kan ook gewoon alles aan wat je ermee wilt.

Waar heb je Kodi vandaan eigenlijk voor je CentOS 7? Het staat namelijk niet standaard in de EPEL repo. Linken naar bepaalde libraries gebeurt tijdens het compileren adhv de development headers die je hebt. Als Kodi bijvoorbeeld tegen libmodplug.so.0 is gecompileerd, dan zal het nooit lekker gaan werken op een systeem dat alleen libmodplug.so.1 aanbied. Andersom net zo uiteraard.

[jb044]

Stukje gewenning, ooit begonnen met RedHat 5.2 in '96, enerzijds en praktische overwegingen anderzijds: we nemen @work een CentOS cluster af bij een dedicated hosting partij, dus wel zo handig om dat thuis ook te hebben voor de nodige experimenten.

Om precies te zijn gewoon via kodi.tv en als basis de spec file van rpmfusion die ik dus aangepast heb met wat vallen en opstaan om de binary addons van kodi mee te nemen. Vreemde is dan dat zowel de binary als headers van libmodplug komen van de rpm en devel rpm die de .so.1 bieden. Zal eens kijken of daar wat niet snor zit, maar eigenwijs als ik ben denk ik eerder dat ik het in de kodi sources moet zoeken .... maar ben ook opportunistisch, dus wordt graag verbeterd als dat voor mijn eigen bestwil is

[Hero of Time]

Ik kan je verzekeren, het staat niet in de source code. Het zijn niet voor niets dynamische libraries. Je zou helemaal niets hoeven aan te passen aan de code. Je moet juist in de spec-file kijken, want die bepaald hoe je binaire bestanden eruit komen te zien en wat er nodig is als dependencies. Dat laatste zou al door het yum commando moeten worden meegenomen om te bepalen of het wel of niet te installeren is. Je hebt toch wel 'yum install <kodi>.rpm' gedaan, ipv met het rpm commando?

[jb044]

Uiteraard, maar ik moet je toch teleurstellen: het stond wel in de source

Ergens stond een verwijzing naar libmodplug 0.8.7, een nogal oude versie, dat aangepast, opnieuw rpmbuild gedraaid en:

# rpm -Uvh --force kodi-16.1-2.el7.centos.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:kodi-16.1-2.el7.centos ################################# [100%]

Merk op: geen melding meer over ontbrekende libraries

Ik zal vast iets vreselijk fout doen en met de verkeerde software werken, maar voorlopig kan ik weer mooi verder

PS dank aan Tralas, je gaf me niet het antwoord maar zette me wel op het juiste spoor: niet zorgen voor libmodplug.so.0 maar zorgen dat de bestaande versie gewoon netjes opgepikt wordt.

[igmar]

Hero of Time schreef op woensdag 30 november 2016 @ 23:25:
Wat weerhoud je er eigenlijk van om CentOS 7, wat toch wel redelijk outdated software bevat, te verruilen voor een wat nieuwere distro? Ubuntu 16.04 is bijvoorbeeld een recente release en kan zonder enige problemen Kodi aan en alles wat je er nog meer op wil draaien. Vind je Ubuntu niks, of twijfel je, dan kan je altijd nog Debian Jessie (huidige Stable) nemen. Die is recenter dan CentOS, maar wat meer uitontwikkeld dan Ubuntu 16.04 en kan ook gewoon alles aan wat je ermee wilt.

Omdat sommige mensen, waaronder ik, nou niet bepaald fan zijn van alles wat maar op .deb gebaseerd is ?

Waar heb je Kodi vandaan eigenlijk voor je CentOS 7? Het staat namelijk niet standaard in de EPEL repo. Linken naar bepaalde libraries gebeurt tijdens het compileren adhv de development headers die je hebt. Als Kodi bijvoorbeeld tegen libmodplug.so.0 is gecompileerd, dan zal het nooit lekker gaan werken op een systeem dat alleen libmodplug.so.1 aanbied. Andersom net zo uiteraard.

Over het algemeen werkt rebuilden van de packages die er zijn prima. Ik doe niet anders, vooral als ik een veel nieuwere / bepaalde versie van iets nodig heb.

[Hero of Time]

igmar schreef op donderdag 8 december 2016 @ 09:29:
[...]

Omdat sommige mensen, waaronder ik, nou niet bepaald fan zijn van alles wat maar op .deb gebaseerd is ?

Dan ga je naar Fedora of SuSE toe. Net om het even, als je maar iets neemt dat wat recentere software en libraries heeft.

[...]

Over het algemeen werkt rebuilden van de packages die er zijn prima. Ik doe niet anders, vooral als ik een veel nieuwere / bepaalde versie van iets nodig heb.

Dat zeg je goed, 'over het algemeen werkt het. Dus niet altijd en ook niet met alles. Kijk je ook in het .spec file voor uiteindelijke dependencies en pas je aan waar nodig? Dus niet wat je nodig hebt om te compileren, maar de dependencies als je 'm gaat installeren. Het is namelijk niet zo eenvoudig als de source downloaden en een rpmbuild eroverheen gooien.

[igmar]

Hero of Time schreef op donderdag 8 december 2016 @ 10:31:
Dan ga je naar Fedora of SuSE toe. Net om het even, als je maar iets neemt dat wat recentere software en libraries heeft.

Ik heb het eigenlijk nooit nodig, en over het algemeen genomen heb ik er alleen maar last van : Zaken met zeer recente versies die subtiel breken onder bepaalde condities.

Ik kan me voorstellen dat als je een desktop draait het wel relevant is.

Dat zeg je goed, 'over het algemeen werkt het. Dus niet altijd en ook niet met alles. Kijk je ook in het .spec file voor uiteindelijke dependencies en pas je aan waar nodig? Dus niet wat je nodig hebt om te compileren, maar de dependencies als je 'm gaat installeren. Het is namelijk niet zo eenvoudig als de source downloaden en een rpmbuild eroverheen gooien.

Als je weet waar je mee bezig bent is het zelden een issue. En ja, dat betekend altijd de .spec file doorlopen. Het grootste issue is multilib, maar aangezien i386 behoorlijk aan het uitsterven is is het steeds minder een issue.

[Verwijderd]

CentOS is geen distributie die is gemaakt voor zaken zoals KODI. Uiteraard kun je dat gebruiken maar ik ben het met Hero of Time eens dat dit voor een dergelijke toepassing niet de meest voor de hand liggende keuze is. Vooral dat ENT in de CentOS naam zegt wel iets. Ik werk ook zakelijk met RHEL 5/6/7 maar dat wil niet zeggen dat ik prive ook deze software draai. Ik kies voor een meer op consumenten gerichte, modernere distributie die (lui als ik tegenwoordig ben) allerlei geneuzel al voor je heeft opgelost. En dat die distributie toevallig .deb packages gebruikt vind ik prima, vooral de zeer uitgebreide standaard repo is een genot Geen dependency RPM hell meer voor mij want daar word ik alleen maar erg verdrietig van.

[jb044]

Als ik alleen kodi op deze machine zou draaien was CentOS idd een rare keuze geweest, maar dat is niet het geval. Machine is ooit in een andere hw config begonnen als server en later na een verhuizing ook dienst gaan doen als media centre. Maar ook nu nog is het hoofdzakelijk server en los daarvan als je zoals ik met RedHat kan lezen en schrijven en veel minder werkt met debian of ubuntu is er toch nog wat voor te zeggen. Bij Fedora heb je de latest & greatest maar zul je dat weten ook. Op mijn workstation heb ik bv pas sinds +/- 1 week een werkende screensaver, daarvoor een poos een full hd screensaver op een uhd scherm (oftewel een screensaver met exact 25% vulling!) en weer daarvoor een weliswaar werkende screensaver maar wel met glitches als een taakbalk die gewoon bleef uitklappen in screensaver modus ..... niet wereldschokkend allemaal maar imho toch een duidelijk voorbeeld de ehm 'Fedora expierence'.

TLDR; je hebt als RH fan toch de keus uit af en toe en in afnemende mate zelf wat compilen, als het ff kan netjes met rpmbuild of mock, of heel veel keus en gemak maar ook veel glitches en dingen die af en toe omvallen.