[FreeBSD] Shared object not found

Pagina: 1
Acties:
  • 490 views sinds 30-01-2008
  • Reageer

  • Demo
  • Registratie: Juni 2000
  • Laatst online: 29-01 13:56

Demo

Probleemschietende Tovenaar

Topicstarter
Ik ben bezig om een minimale FreeBSD-installatie in elkaar te zetten voor een embedded toepassing. Hoewel ik hier eigenlijk geen uitgebreide interface nodig heb, lijkt het mij erg handig om Bash op dit systeem beschikbaar te hebben. Wanneer ik echter probeer om op het embedded systeem Bash te starten krijg ik de volgende foutmelding:
/libexec/ld-elf.so.1: Shared object "libintl.so.8" not found, required by "bash"
Het vreemde is echter dat /usr/local/lib/libintl.so.8 wel aanwezig is :?
Via Google kwam ik diverse mogelijke oplossingen tegen, onder andere het opnieuw installeren van de applicatie en het aanmaken van diverse symlinks, maar dit heeft allemaal geen resultaat gehad.

Unix doesn't prevent a user from doing stupid things, because that would necessarily prevent them from doing brilliant things.
while true ; do echo -n "bla" ; sleep 1 ; done


  • GX
  • Registratie: Augustus 2000
  • Laatst online: 14-05-2025

GX

Nee.

Weet ld wel dat hij moet zoeken in /usr/local/lib/ ? Probeer anders eens een symlink t emaken vanuit /usr/lib/

  • blaataaps
  • Registratie: Juli 2001
  • Niet online
Je "minimale installatie" en "embedded toepassing" conflicteren nogal met "ik moet bash erop".
Wat je kunt doe is proberen bash statisch te compileren, dan heb je geen gedoe met library's die ontbreken, maar ik zou aanraden is bash laten voor wat het is en een kleinere shell nemen zoals bijvoorbeeld (d)ash. Ik denk dat de meeste minimale shells voor 99% al kunnen wat men zoal gebruikt in uitgebreidere shells.

  • Demo
  • Registratie: Juni 2000
  • Laatst online: 29-01 13:56

Demo

Probleemschietende Tovenaar

Topicstarter
GX schreef op woensdag 25 april 2007 @ 16:53:
Weet ld wel dat hij moet zoeken in /usr/local/lib/ ? Probeer anders eens een symlink t emaken vanuit /usr/lib/
Hoe laat ik ld dat weten? :P
blaataaps schreef op woensdag 25 april 2007 @ 16:57:
Je "minimale installatie" en "embedded toepassing" conflicteren nogal met "ik moet bash erop".
Wat je kunt doe is proberen bash statisch te compileren, dan heb je geen gedoe met library's die ontbreken, maar ik zou aanraden is bash laten voor wat het is en een kleinere shell nemen zoals bijvoorbeeld (d)ash. Ik denk dat de meeste minimale shells voor 99% al kunnen wat men zoal gebruikt in uitgebreidere shells.
Ergens heb je wel gelijk :) Echter heeft mijn embedded bordje (PCEngines WRAP) voldoende power en ruimte om het te kunnen draaien, vandaar.

Unix doesn't prevent a user from doing stupid things, because that would necessarily prevent them from doing brilliant things.
while true ; do echo -n "bla" ; sleep 1 ; done


Verwijderd

De foutmelding komt van een update van gettext. Zie /usr/ports/UPDATING hiervoor. Houd er rekening mee dat erg veel ports gebruik maken van gettext en die moeten dus allemaal opnieuw gecompileerd worden:
...
20070318:
AFFECTS: users of devel/gettext (ie: YOU)
AUTHOR: ade@FreeBSD.org

As a result of the upgrade to gettext-0.16.1, the shared library version
of libintl has changed, so you will need to rebuild all ports that
depend on gettext (ie: most of them, sorry):

portupgrade -rf gettext

or

portmaster -r gettext

In addition, if you have multimedia/vlc installed, you should deinstall
it *before* either of the above commands, and reinstall it manually
afterwards - vlc erroneously installs its own version of lib/charset.alias
which will overwrite the one supplied by devel/gettext otherwise.
...

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:18
Verwijderd schreef op woensdag 25 april 2007 @ 17:35:
De foutmelding komt van een update van gettext. Zie /usr/ports/UPDATING hiervoor. Houd er rekening mee dat erg veel ports gebruik maken van gettext en die moeten dus allemaal opnieuw gecompileerd worden
Dan is het raar dat libintl.so.8 wél aanwezig is het op het systeem. Sowieso is dit ook de laatste release, dus op een FreeBSD 6.2 systeem zou die gewoon aanwezig moeten zijn.
blaataaps schreef op woensdag 25 april 2007 @ 16:57:
Wat je kunt doe is proberen bash statisch te compileren, dan heb je geen gedoe met library's die ontbreken
Dat scheelt op de hele base system natuurlijk praktisch niets. Lijkt me alleen maar nodeloos gedoe (moet je zelf bash gaan configureren in plaats van de standaard port te gebruiken) terwijl het ook normaal hoort te werken.

Ik heb nog twee suggesties: voeg /usr/local/lib toe aan de LD_LIBRARY_PATH environmental variable om zeker te weten dat in die directory gezocht wordt (maar eigenlijk zou dat standaard al moeten gebeuren, dus ik denk dat het niet help), en controleer of /usr/local/lib/intl.so.8 niet toevallig een symlink is.

Verwijderd

Soultaker schreef op woensdag 25 april 2007 @ 17:42:
Dan is het raar dat libintl.so.8 wél aanwezig is het op het systeem. Sowieso is dit ook de laatste release, dus op een FreeBSD 6.2 systeem zou die gewoon aanwezig moeten zijn.
Die wordt door de applicatie nog niet gezien omdat die nog niet gecompileerd is met de nieuwe gettext.

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:18
Dat is dus onzin, als de dynamic loader klaagt dat 'ie libintl.so.8 niet kan vinden. Als Bash tegen een oude versie gelinkt zou zijn, zou 'ie juist om een andere versie vragen (niet de versie die er wel is).

Eventueel kun je nog eens verifiëren welke library dependencies er zijn, met:
ldd /usr/local/bin/bash

Verwijderd

Lijkt me geen onzin. Het staat niet voor niets in /usr/ports/UPDATING en bovendien heb ik hetzelfde probleem gehad met alle applicaties die gettext als dependency hebben. Als je gettext update en bash opnieuw via de ports installeert zou alles goed moeten zijn.

  • Soultaker
  • Registratie: September 2000
  • Laatst online: 02:18
Verwijderd schreef op woensdag 25 april 2007 @ 18:18:
Het staat niet voor niets in /usr/ports/UPDATING
In UPDATING wordt inderdaad vermeld als een belangrijke library geüpdatet is, maar dan wordt óók het versienummer van de .so-file opgehoogd (daar is dat nummer voor). Dan krijg je bij het opstarten van de executable dus de melding dat 'ie foobar.so.123 nodig heeft, terwijl je foobar.so.124 geïnstalleerd hebt.

Volgens de TS is dat echter niet het geval: de executable vraagt om libintl.so.8 en hij hééft libintl.so.8; die zou 'ie dus gewoon moeten kunnen gebruiken (hoewel die in theorie incompatible kan zijn, maar dan krijg je een andere melding dan "so not found").
en bovendien heb ik hetzelfde probleem gehad met alle applicaties die gettext als dependency hebben.
Weet je zeker dat je precies hetzelfde probleem had? Het lijkt mij namelijk veel waarschijnlijker dat je het eerder genoemde probleem had (executable heeft een dependency op een library die na upgraden niet meer op het systeem aanwezig is).

Overigens treedt dit probleem meestal niet op omdat libraries gebackupt worden in /usr/local/lib/compat/, maar je kunt het wel stuk maken (vooral op -CURRENT) door packages die niet voor jouw release bedoeld zijn te installeren.

Verwijderd

Soultaker schreef op woensdag 25 april 2007 @ 20:49:
Weet je zeker dat je precies hetzelfde probleem had? Het lijkt mij namelijk veel waarschijnlijker dat je het eerder genoemde probleem had (executable heeft een dependency op een library die na upgraden niet meer op het systeem aanwezig is).
Ook op mijn systeem was de library aanwezig terwijl ik deze melding kreeg. Het verschijnsel deed zich dan ook helaas, na de update van gettext, bij alle applicaties voor die gettext als dependency hebben.

  • Demo
  • Registratie: Juni 2000
  • Laatst online: 29-01 13:56

Demo

Probleemschietende Tovenaar

Topicstarter
Verwijderd schreef op woensdag 25 april 2007 @ 17:35:
De foutmelding komt van een update van gettext. Zie /usr/ports/UPDATING hiervoor. Houd er rekening mee dat erg veel ports gebruik maken van gettext en die moeten dus allemaal opnieuw gecompileerd worden:
...
20070318:
AFFECTS: users of devel/gettext (ie: YOU)
AUTHOR: ade@FreeBSD.org

As a result of the upgrade to gettext-0.16.1, the shared library version
of libintl has changed, so you will need to rebuild all ports that
depend on gettext (ie: most of them, sorry):

portupgrade -rf gettext

or

portmaster -r gettext

In addition, if you have multimedia/vlc installed, you should deinstall
it *before* either of the above commands, and reinstall it manually
afterwards - vlc erroneously installs its own version of lib/charset.alias
which will overwrite the one supplied by devel/gettext otherwise.
...
Ik ben pas 2 weken terug begonnen met het installeren van dit systeem en heb toen ook een verse ports-tree binnengehaald.
Soultaker schreef op woensdag 25 april 2007 @ 18:10:
Dat is dus onzin, als de dynamic loader klaagt dat 'ie libintl.so.8 niet kan vinden. Als Bash tegen een oude versie gelinkt zou zijn, zou 'ie juist om een andere versie vragen (niet de versie die er wel is).

Eventueel kun je nog eens verifiëren welke library dependencies er zijn, met:
ldd /usr/local/bin/bash
Heb ik gebruikt en alle libraries die daar aangegeven worden, heb ik gekopieerd.

Het gebruik van de variabele LD_LIBRARY_PATH lijkt het probleem op te lossen - als ik dit vanaf de command prompt doe dan kan ik daarna zonder problemen Bash opstarten. De enige (beginners) vraag die ik nu nog heb is: in welk script moet ik deze variabele opgeven zodat hij bij het starten van het systeem gevuld wordt? En wat moet er precies in komen (ik heb nu: LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib)

Unix doesn't prevent a user from doing stupid things, because that would necessarily prevent them from doing brilliant things.
while true ; do echo -n "bla" ; sleep 1 ; done


Verwijderd

eh, mischien een hele gekke vraag hoor, maar heb je je library cache ge-update? (ldconfig -m /usr/local/lib)

  • GX
  • Registratie: Augustus 2000
  • Laatst online: 14-05-2025

GX

Nee.

Gewoon in je /etc/profile duwen?

Verwijderd

GX schreef op donderdag 26 april 2007 @ 11:44:
Gewoon in je /etc/profile duwen?
LD_LIBRARY_PATH is lelijk en zou je ook niet moeten gebruiken tenzij je echt niet anders kan. Dit is precies iets waar ze library cache's voor uitgevonden hebben ;)

  • P5ycho
  • Registratie: Januari 2000
  • Laatst online: 22:34
Even een kleine toevoeging:
bij mijn fbsd7 install waren de permissies van /var/run fuckedup.
chmod 755 /var/run
en het liep weer.

12x 280Wp ZW, 12x 280Wp ZO, Zubadan SHW80YAA 8kW, Zehnder Q450 ERV


  • Demo
  • Registratie: Juni 2000
  • Laatst online: 29-01 13:56

Demo

Probleemschietende Tovenaar

Topicstarter
Even een schopje tegen dit topic.. ik heb onlangs mijn projectje weer opgepakt. Het probleem wat ik hier had werd inderdaad veroorzaakt door de library cache. Echter omdat ik vanaf een CF-kaart werk, is mijn filesystem read-only, met uitzondering van /var en /tmp die bij het booten als memorydisk worden gemount. Om die reden kan ik niet ld.so.hints en ld-elf.so.hints in /var/run plaatsen. Ik had dit als test opgelost door ldconfig ergens in /etc/rc te kliederen en dat werkte op zich wel, maar is natuurlijk niet 'zoals het hoort'. Is het mogelijk om een scriptje in rc.d/ te plaatsen dat bij het opstarten de map /var/run aanmaakt en daarin de eerder genoemde bestanden aanmaakt (het zij kopiëren vanuit een andere map, het zij ldconfig aanroepen) en eventueel nog wat andere dingen doet? (ik moet /var/run, /var/log en nog wat dingen binnen /var aanmaken)
Een ander iets wat ik mij afvroeg, ik heb puur uit interesse ook deze guide gevolgd, om eens te kijken wat nou de absolute basis is van FreeBSD om te kunnen booten. Is er documentatie waarin staat uitgelegd hoe de bootprocedure (init, sysctl, login en dergelijke processen) verloopt? In het online Handbook kon ik hier niets over vinden en ook de man-pages zijn er niet heel duidelijk over.

Unix doesn't prevent a user from doing stupid things, because that would necessarily prevent them from doing brilliant things.
while true ; do echo -n "bla" ; sleep 1 ; done

Pagina: 1