First Light for LibreOffice on Solaris 11

  • Posted on: 30 October 2015
  • By: tomww
Screenshot of LibreOffice first light on Solaris 11

Update 20151031: Packages uploaded! \o/

Upgrade your Solaris to 11.3, then do "pfexec pkg install -v libreoffice4-desktop-int".

OTN Users of S11.2 GA (no extra SRU!) need to wait or better upgrade to S11.3 - you *really* want this. ==(click on the headline to see the full article)

Dear Readers, after a long way, I can announce the "first light" for LibreOffice on Solaris 11. I'll make an IPS package of this first build and upload this to the "localhosts11" repository. A second build run will take during the day and include dictionaries and language support in the GUI. Please test this package and report back if it works for you! Have fun and please share the news!!

Regards, Thomas

PS:This is how it looks like:

Tags: 
first light LibreOffice libreoffice4 office S11 Solaris 11

Comments

Vermilion

Sat, 10/31/2015 - 20:35

Great news, just tested under Oracle Solaris 11.3, installs and starts without any errors. I have to confirm the gnome-tetminal issue. (See post below)

Regards Verm

slx86

Mon, 11/02/2015 - 11:01

After install LO gnome-terminal coredump@start.

After some searching i found that the library/desktop/gnu/cairo is the offending packages. The /usr/gnu/lib/libcairo.so.2 the library.

Looking with ldd to the gnome-terminal its using the RUNPATH/RPATH from /usr/lib/libvte.so.9 which gives /usr/gnu/lib priority above the crle paths.

So what can i do to prevent this behaviour

Update: for now, with elfedit i changed the search order
elfedit -r -e 'dyn:runpath' /usr/lib/libvte.so.9
elfedit -r 'dyn:runpath /usr/lib:/usr/gnu/lib' /usr/lib/libvte.so.9
elfedit -r -e 'dyn:runpath' /usr/lib/libvte.so.9
Sjaak

tomww

Mon, 11/02/2015 - 11:09

Hi Sjaak,

thank you for your feedback and the good analysis!
Normally there should be no such interference built in, as the additional SFE cairo library should
not be found by gnome-terminal. But as you wrote, if gnome-terminal / libvte explicitly lists in RPATH /usr/gnu/lib
and this should be the cause. I'll see if gnome-terminal really needs /usr/gnu/lib in its RPATH and what the
solution could be. Probably one should file a bug against the libvte library to stop listing /usr/gnu/lin in RPATH.

What I have to investigate is, what a short-term (interim) solution could be to free up regular Solaris 11 users
from elfedit the binaries. Maybe I'll relocate the cairo lib (and poppler if necessary) to another directory.

Thank you!
Regards,
Thomas

Vermilion

Mon, 11/02/2015 - 15:35

Thank you slx86 for that good analysis. Nice to see some feedback!

Best Regards

Verm

slx86

Wed, 11/04/2015 - 12:19

You're welcome.

To make the LD_LIBRARY_PATH setting more permanent its possible to make a alias in the .bashrc or .profile
alias gnome-terminal='LD_LIBRARY_PATH=/usr/lib /usr/bin/gnome-terminal'

hopefully the aren't more programs's that use vte this way

Sjaak

tomww

Thu, 11/05/2015 - 22:17

A new build is in on the workbench.
It will have a SFEcairo-gpp relocated to /usr/g++, so libvte / gnome-terminal just doesn't see it.
Additionally I#ve added a SFEpoppler-data package (for what it's worth).

While I'm editing this comment again, the packages are already uploaded now.
I can use help from a few testers now.

Please, hands up!

The Test is as follows. First a dry-run, you can see what will be changed.
Second, the real install:

pfexec pkg update -nv

You should see packages removed "-> None" and packages added "None -> "

Then do the real update with:

pfexec pkg update -v

Regards
tomww