Kirjoittaja Aihe: Ympäristömuuttuja LD_LIBRARY_PATH ? [Ratkaistu]  (Luettu 2444 kertaa)

New_user

  • Käyttäjä
  • Viestejä: 1247
    • Profiili
Ongelmasta toiseen :D

Otsikossa mainittu ympäristömuuttuja pitäisi saada asetetuksi, muttei onnistu asettaminen missään tiedostossa, missä se normaalisti asetetaan (/etc/environment, .profile  jne.) Arvoksi pitäisi saada /opt/libjpeg-turbo. Netistä löysin, että tämä olisi vieläkin(?) avoinna oleva bugi, ja erittäin harmillinen.

Onko hyvää ratkaisua olemassa? En oikein ymmärtänyt, mitä purkkavirityksiä pitäisi kenties tehdä.
« Viimeksi muokattu: 16.10.13 - klo:14.30 kirjoittanut New_user »

mrl586

  • Käyttäjä
  • Viestejä: 4638
    • Profiili
Vs: Ympäristömuuttuja LD_LIBRARY_PATH ?
« Vastaus #1 : 16.10.13 - klo:09.25 »

New_user

  • Käyttäjä
  • Viestejä: 1247
    • Profiili
Vs: Ympäristömuuttuja LD_LIBRARY_PATH ?
« Vastaus #2 : 16.10.13 - klo:10.12 »
Export-komento?
http://linux.fi/wiki/Export

Öö, sen antaminen .profile-tiedostossa ei toimi sellaisenaan. Tämä LD_LIBRARY_PATH on joku erikoistapaus.
Yhden konstin löysin,  /etc/X11/Xsession.options -tiedostoon no use ssh-agent, jonka jälkeen .profilessa saa muuttujan pelaamaan. Tämäkään tosin ei ratkaissut lopullista ongelmaa, mutta se on taas toinen juttu. Tänks enivei...

nm

  • Käyttäjä
  • Viestejä: 16375
    • Profiili
Vs: Ympäristömuuttuja LD_LIBRARY_PATH ?
« Vastaus #3 : 16.10.13 - klo:10.50 »
LD_LIBRARY_PATH-muuttujan asetus .profile:ssa, .bashrc:ssä ja /etc:n vastaavissa järjestelmänlaajuisissa tiedostoissa toimii kyllä uusissa Bash-istunnoissa. Ongelmasi koskee ilmeisesti muuttujan asettamista koko työpöytäistunnolle. Se ei välttämättä toimi siksi, että kirjautumismanageri tyhjentää LD_LIBRARY_PATH:n turvallisuussyistä.

Sen sijaan voisit asettaa polun ld.so.conf(.d):n kautta. Tämä asettaa sen selvitettävien polkujen alkupäähän:

Koodia: [Valitse]
echo '/opt/libjpeg-turbo' | sudo tee /etc/ld.so.conf.d/00-libjpeg-turbo.conf
Jos korvaat "00":n "zz":lla, kyseinen tiedosto ja polku käsitellään vasta viimeisten joukossa, jolloin kirjasto ei taida korvata järjestelmään asennettua libjpegiä.

Perään voi ajaa vielä komennon sudo ldconfig, jotta muutos tulee voimaan.


Mikä muuten on tavoitteesi tässä itse asennetun libjpeg-turbon käytössä? Ubuntussahan se on nykyisin valmiiksi asennettuna ja kaikki ohjelmat, jotka riippuvat libjpeg8:sta (eli käytännössä kaikki jakelun jpeg-formaattiin liittyvät toiminnot) käyttävät sitä oletuksena.
« Viimeksi muokattu: 16.10.13 - klo:10.54 kirjoittanut nm »

New_user

  • Käyttäjä
  • Viestejä: 1247
    • Profiili
Vs: Ympäristömuuttuja LD_LIBRARY_PATH ?
« Vastaus #4 : 16.10.13 - klo:11.35 »
.
Mikä muuten on tavoitteesi tässä itse asennetun libjpeg-turbon käytössä? Ubuntussahan se on nykyisin valmiiksi asennettuna ja kaikki ohjelmat, jotka riippuvat libjpeg8:sta (eli käytännössä kaikki jakelun jpeg-formaattiin liittyvät toiminnot) käyttävät sitä oletuksena.


Hmm. Mistä sitä voi tietää, onko ko. turbo jo jakelussa mukana, kun sitten Geoserverin ohjeissa tulee näin:

http://docs.geoserver.org/stable/en/user/community/libjpeg-turbo/index.html

Jos se on tosiaan asennettuna ilman mitään, niin 12.04:ssä kuin 12.04-serverissäkin, niin homma oli sitten tässä?

EDIT: Sain tiimiltä oheisen viestin, mutta silti ei ole selvää, pitäisikö extra libjpeg-turbo olla asennettuna vaiko ei? Tästä kuitenkin selviää, mihin tuo ympäristömuuttuja pitäisi selvittää. Ohje oli kaiken kaikkiaan hieman epämääräinen. Ja mikähän lienee JNI-library?

Lainaus
I'm a colleague of -------- working on Linux.
Never tried out the libjpeg-turbo linux package but tried to follow the instructions and got things working in 10 minutes, but I indeed had to overcome an issue.
There is a catch in the instructions that is not clear, most recent Linux distributions already have libjpegturbo installed, but the
packages stripped the JNI library out of it.

When you install the official package from libjpegturbo, another (more recent) version of libjpegturbo is installed in /opt as you
said, and so it's mandatory to setup LD_LIBRARY_PATH. The trick is, the new directory it has to be the first element in the
path, otherwise the system one will be used and the JNI library won't recognize it (since it's a different version).

So I've modified catalina.sh adding this:
export LD_LIBRARY_PATH=/opt/libjpeg-turbo/lib64:$LD_LIBRARY_PATH

After setting it the logs read:

2013-10-16 10:14:01,701 WARN [turbojpeg.TurboJPEGMapResponse] - The turbo jpeg encoder is available for usage

Kysyin tiimiltä vielä:

But still a one more question. Is it totally waste of time to install this extra libjpeg-turbo at all, when talking about Ubuntu 12.04 and 12.04 server?

ja vastaus (nimet poistettu)

Lainaus
Not at all, unfortunately the Ubuntu official packages stripped the JNI bridge library making them unusable for GeoServer (or, alternatively,
it's too old a version, not sure which of the two actually).

So, you have to install the Turbojpeg official packages  instead, and set LD_LIBRARY_PATH as me and ------ showed


« Viimeksi muokattu: 16.10.13 - klo:11.56 kirjoittanut New_user »

nm

  • Käyttäjä
  • Viestejä: 16375
    • Profiili
Vs: Ympäristömuuttuja LD_LIBRARY_PATH ?
« Vastaus #5 : 16.10.13 - klo:12.57 »
Hmm. Mistä sitä voi tietää, onko ko. turbo jo jakelussa mukana

Kyllä se on 12.04:ssä oletuksena. Ainoa toinen libjpeg-kirjasto on vanha libjpeg62. Asia selviää tutkimalla paketointia esimerkiksi http://packages.ubuntu.com -sivuston ja apt-cache showpkg -komennon avulla. libjpeg8 on tyhjä riippuvuuspaketti, joka asentaa libjpeg8-turbon. apt-cache showpkg libjpeg8 kertoo "Reverse depends" -tiedoissa, että lähes kaikki Ubuntun jpeg-formaattia käsittelevät ohjelmat ja kirjastot riippuvat kyseisestä paketista ja siten edelleen libjpeg8-turbosta. Pieni osa ohjelmista riippuu vielä vanhasta libjpeg62:sta. Ubuntu 13.04:ssä näistäkin jäänteistä on päästy eroon.


EDIT: Sain tiimiltä oheisen viestin, mutta silti ei ole selvää, pitäisikö extra libjpeg-turbo olla asennettuna vaiko ei? Tästä kuitenkin selviää, mihin tuo ympäristömuuttuja pitäisi selvittää. Ohje oli kaiken kaikkiaan hieman epämääräinen. Ja mikähän lienee JNI-library?

GeoServer on java-ohjelma, joten se käyttää JNI-rajapintaa natiivikoodin kutsumiseen. Alkuperäisessä libjpegissä ei ole lainkaan JNI-tukea vaan se on lisätty libjpeg-turboon. Debianin ja Ubuntun libjpeg-turbo-paketoinnista JNI on jätetty pois varmaankin siksi, ettei mikään jakeluun kuuluva java-ohjelma käytä sitä. Normaalisti java-ohjelmat käsittelevät jpeg-kuvia JRE:n luokkakirjastojen kautta ja siellä on käsittääkseni oma JNI-rajapinta libjpegille (eli käytännössä jakelun libjpeg-turbolle).

Saadun ohjeistuksen perusteella tarvitset siis erillisen, JNI-tuella käännetyn libjpeg-turbon GeoServerin libjpeg-turbo-pluginia varten. Tällaisissa yksittäistapauksissa LD_LIBRARY_PATH on tosiaan parempi paikka kirjaston määrittelyyn ja sen voi asettaa GeoServerin Tomcat-käynnistysskriptissä, kuten kontaktisi neuvoi. Silloin kirjasto ei pääse myöskään sotkemaan muiden ohjelmien toimintaa.

Selvitettäväksi jää, saavutetaanko GeoServerin libjpeg-turbo-pluginilla olennaista nopeutusta nykyisissä Linux-jakeluissa, kun GeoServer tavallisesti käsittelee jpeg-kuvia JRE:n luokkien avulla. Se saattaa päätyä käyttämään libjpeg-turboa joka tapauksessa.
« Viimeksi muokattu: 16.10.13 - klo:13.00 kirjoittanut nm »

New_user

  • Käyttäjä
  • Viestejä: 1247
    • Profiili
Vs: Ympäristömuuttuja LD_LIBRARY_PATH ?
« Vastaus #6 : 16.10.13 - klo:13.17 »
Selvitettäväksi jää, saavutetaanko GeoServerin libjpeg-turbo-pluginilla olennaista nopeutusta nykyisissä Linux-jakeluissa, kun GeoServer tavallisesti käsittelee jpeg-kuvia JRE:n luokkien avulla. Se saattaa päätyä käyttämään libjpeg-turboa joka tapauksessa.

Okei, onpahan sitten asennettu vaikkapa varmuuden vuoksi. Ohjeen pathista korjasin vain /lib64 ->/lib32 ja Geoserverin loki ilmoitti turbon menneen päälle :) Mahdollisimman tehokas kirjasto auttaa rasterikartan (esim. geotiff) sylkäisyssä verkkoon pikaiseen. Rasterit ovat raskaahkoja käsitellä. Java tässä on muutenkin optimoitu aika hyvin.

Tämä nyt sekosi alkuperäisestä aiheesta vähän sivupolulle, mutta varmaankin LD_LIBRARY_PATH -muuttujan hankaluus, ja oikopolut ongelman kiertämiseen tulivat lukijoiden tietoon myös. Kiitos!