Új hozzászólás Aktív témák

• #95252 PCProfessor aktív tag RaZroX #95250

  Új Válasz 2024-04-09 13:33:09 #95252

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  PCProfessor

  aktív tag

  válasz RaZroX #95250 üzenetére

  Tömören? Hiányzó/eltérő függőségek okozták a gondot.
  
  Ilyenkor van az, sok lehetőség van instalállni valamit de egyik megoldás sem működik alapjáraton, mókolás nélkül.

• #95251 urandom0 senior tag RaZroX #95250

  Új Válasz 2024-04-09 09:17:25 #95251

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  urandom0

  senior tag

  válasz RaZroX #95250 üzenetére

  ERROR: ld.so: object '/usr/lib64/libglib-2.0.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
/opt/resolve/bin/resolve: symbol lookup error: /lib64/libgdk_pixbuf-2.0.so.0: undefined symbol: g_task_set_static_name

  Itt az volt a baj, hogy a Davinci a g_task_set_static_name függvényt szerette volna meghívni (ez a GLib 2.76-os verziójától érhető el), de a /lib64/libgdk_pixbuf-2.0.so.0 fájlban nem találta meg.

  A Fedorában ugyan 2.78-as libglib van, úgyhogy ennek elméletileg jónak kellene lennie. VISZONT a Davinci mellé odacsomagoltak egy rakat libet (a libs mappában), és balfék módjára sikerült nekik a 2.68-as libglib-et mellécsomagolni, amiben valóban nincs benne a g_task_set_static_name függvény. Ezért kell elmozgatni vagy kitörölni a libs mappából ezt és az ezzel kapcsolatban álló libeket, és akkor már a Davinci a rendszer libjét fogja használi, ami viszont teljesen jó.

  Egy másik megoldás, ami jó lehetett volna, a disztró által biztosított lib átmásolása a Davinci mappájába: sudo cp /usr/lib64/libglib-2.0.so.0 /opt/resolve/libs/, felülírva az ott lévőt libet.
  Hogy ez miért nem műkődött, azt nem tudom, lehet, hogy még több libet is át kellett volna másolni, vagy valamiért nem írta felül a Davinci libglib-jét...

  Ez a megoldás pedig:
  LD_PRELOAD="/usr/lib64/libglib-2.0.so" /opt/resolve/bin/resolve
  Ez arra utasítja a resolve-t, hogy a /usr/lib64/libglib-2.0.so-t töltse be a sajátja helyett.

  A libpango esetében majdnem ugyanez a szitu, a program a g_string_free_and_steal függvényt hívná, viszont a libpango nem volt telepítve. Ezért írtam, hogy ha már így is egy rakat libet odacsomagoltak a program mellé, miért nem voltak képesek odarakni a libpango-t is?
  Eléggé elbszott egy terjesztési forma ez, de szerintük ezzel így nincs probléma... hát, oké.
  Csak annyit kell bemásolni a Google-ba, hogy g_task_set_static_name, és látszik, mennyire nincs probléma vele (kb. kétezer topik van, ami erről a hibáról szól).

Új hozzászólás Aktív témák