TCL 64: Libreoffice Draw and Impress not working

[lizardidi]

Not sure if this is a bug:

On TCL 64 (not tested for TCL32) libreoffice unable to launch Draw and Impress. Other programs eg Writer, Calc, Math are working.

The error message when try to launch Draw:

loading component library <file:///usr/local/lib/libreoffice/program/../program/libsdlo.so> failed.

https://ibb.co/GJsv18c

Whereas when try to launch Impress, no error displayed. When checked with htop, impress is running in the background.


Did a web search, and found varied and inconsistent solutions. Most user solved this by updating the packages. 

[Juanito]

/usr/local/lib/libreoffice/program/../program/libsdlo.so resolves to /usr/local/lib/libreoffice/libsdlo.so, but the library is in /usr/local/lib/libreoffice/program/libsdlo.so along with all of the other libraries, so I guess this is a bug.

Compiling libreoffice is a mammoth task, but I'll add it to the to do list.

[yvs]

> /usr/local/lib/libreoffice/program/../program/libsdlo.so resolves to /usr/local/lib/libreoffice/libsdlo.so, but
>
  "program/../program" resolves to "program", doesn't it?
  There's a pack with unresolved external packages (like postgres openldap python etc.) there, it's true too. But I suppose it's related to some language settings in this case.

[Juanito]

Ooops, yes you’re correct..

[Rich]

Hi Juanito
The TC14 x86_64 repo has the same version. I installed it in my
TC14 setup and draw threw the same error message.

My TC10 32 bit setup already had libreoffice installed. I loaded
it and the draw application came up.

I think I may have found something. From my TC14 setup:

Code: [Select]

tc@box:/usr/local/lib/libreoffice/program$ for F in `ls lib*.so`; do ldd $F | grep found && echo -e "     $F\n"; done
        libldap-2.4.so.2 => not found
        liblber-2.4.so.2 => not found
     libldapbe2lo.so

        libldap-2.4.so.2 => not found
        liblber-2.4.so.2 => not found
     libpostgresql-sdbc-impllo.so

        libpython3.6m.so.1.0 => not found
        libpython3.6m.so.1.0 => not found
     libpythonloaderlo.so

        libpython3.6m.so.1.0 => not found
     libpyuno.so

tc@box:/usr/local/lib/libreoffice/program$The file list after each  not found  group is the one that threw the error.
Hope this helps. Have to leave for a while.

[Rich]

Hi Juanito
Never mind. I installed the missing dependencies and nothing changed.

Seems the version on my TC10 is missing some deps but it works:

Code: [Select]

tc@E310:/usr/local/lib/libreoffice/program$ for F in `ls lib*.so`; do ldd $F | grep found && echo -e "     $F\n"; done
        libgstpbutils-1.0.so.0 => not found
        libgstvideo-1.0.so.0 => not found
        libgstbase-1.0.so.0 => not found
        libgstreamer-1.0.so.0 => not found
     libavmediagst.so

        libpython3.5m.so.1.0 => not found
        libpython3.5m.so.1.0 => not found
     libpythonloaderlo.so

        libpython3.5m.so.1.0 => not found
     libpyuno.so

tc@E310:/usr/local/lib/libreoffice/program$

[Juanito]

I tried compiling libreoffice-24.8.3.2, but the build fails with:

Code: [Select]

/mnt/sdc1/usr/src/libreoffice-24.8.3.2/workdir/UnpackedTarball/libcmis/src/libcmis/xml-utils.cxx:539:26: error: cannot convert 'unsigned char [20]' to 'unsigned int (&)[5]'
  539 |         sha1.get_digest( digest );
      |                          ^~~~~~
      |                          |
      |                          unsigned char [20]
If anybody else would like to try, please go ahead.

[lizardidi]

Report for libreoffice (and possibly others) appimage on Tiny Core Linux:

In my desperate attempt to try and run libreoffice, I observed some weird behaviour that I not quite understand.

Out of the box, appimages won't run on Tiny Core Linux for my installations. Even after I downloaded fuse.tcz..

When the default libreoffice draw failed to run, I tried to run a copy of libreoffice appimage that long forgotten in my hard drive. As expected, I got the error message and the appimage won't run.

However, one time I unintentionally loaded my ondemand Firefox made with the get_latest_firefox.sh, and unintentionally clicked the libreoffice.appimage... Boom, libreoffice.appimage launched, with every thing (writer, calc, draw, math, impress) all working...!!!

I tested few other smaller appimages, all were launchable after firefox.tcz was loaded.

At first, I thought this was due to a missing dependency get loaded by firefox. Using the dependencies checker, I manually loaded every tcz needed by Firefox.tcz, but the appimage still unable to launch. But once Firefox.tcz get loaded, appimages will run, possibly fuse is needed too.

So.. Beside above, is there a "normal" way to run appimages on Tiny Core?

[CNK]

Firefox_getLatest.sh creates this symlink:

Code: [Select]

ln -s /lib /lib64

That might be what your Appimage needs. Extension dependencies vary between AppImages. In theory any of these libraries might be needed.

[polikuo]

I tried compiling libreoffice-24.8.3.2, but the build fails with:

Code: [Select]

/mnt/sdc1/usr/src/libreoffice-24.8.3.2/workdir/UnpackedTarball/libcmis/src/libcmis/xml-utils.cxx:539:26: error: cannot convert 'unsigned char [20]' to 'unsigned int (&)[5]'
  539 |         sha1.get_digest( digest );
      |                          ^~~~~~
      |                          |
      |                          unsigned char [20]
If anybody else would like to try, please go ahead.

That's a C thing, it can only be solved by the developers.
I'm a hobbyist at best.
Judging by the code, they are trying to cast an unsigned char array (size = 20 x 1 byte = 20 byte) into an unsigned int array (size = 5 x 4 byte = 20 byte).
Presumably to shrink processing time.

However, there should be a work around, checking out the source code leads me here

Code: [Select]

        // on boost <  1.66.0, digest_type is typedef'd as reference to unsigned int[5]
        // on boost >= 1.66.0 and < 1.86.0, digest_type is typedef'd as unsigned int[5]
        // on boost >= 1.86.0, digest_type is typedef'd as unsigned char[20]
#if BOOST_VERSION < 106600
        unsigned int digest[5];
#else
        boost::uuids::detail::sha1::digest_type digest;
#endif
How about just move on to a newer boost ?

[lizardidi]

Firefox_getLatest.sh creates this symlink:

Code: [Select]

ln -s /lib /lib64

That might be what your Appimage needs. Extension dependencies vary between AppImages. In theory any of these libraries might be needed.

Thank you so much!!!

This is exactly what is missing in order to run the libreoffice appimage. 

In order to minimise my save file and ruduce ram use, I put the libreoffice appimage at the root of my save file, then symlinked to /bin. Please do not hesitate to advice me if there is a more efficient and productive way to achieve this. By using appimage this way instead of installing and load libreoffice from the repo, my guess is the ram usage is even less. Am I right?

[CNK]

Thank you so much!!!

This is exactly what is missing in order to run the libreoffice appimage. 

Great! Thanks for reporting back.

In order to minimise my save file and ruduce ram use, I put the libreoffice appimage at the root of my save file, then symlinked to /bin. Please do not hesitate to advice me if there is a more efficient and productive way to achieve this. By using appimage this way instead of installing and load libreoffice from the repo, my guess is the ram usage is even less. Am I right?

By default the repo extensions don't get fully loded into RAM (that's only in copy2fs mode), so they should be roughly equivalent with the AppImage in terms of RAM usage. If by "the root of my save file" you mean the tce directory (where the /etc/sysconfig/tcedir symlink points to), that should be an efficient place to put the AppImage.