Back on topic, @aparsons please try to run LibreOffice from Terminal. Please use this picture as a guide:
Please, share the output.
Here is the output:
It says:
runtime loader: /boot/system/lib/libstdc++.so.6.0.29: version “GLIBCXX_3.4.30” not found (required by libuno_sal.so.3)
Looking at /system/lib I can see libstdc++.so.6.0.29 and have attached its attribute page if that’s any help.
AFAIR there was a GCC bump recently. Could you try to run the pkgman full-sync command in a terminal and reboot afterwards?
1 Like
Thanks,
pkgman full-sync works
shutdown -r works
and now LibreOffice 7.6.2.1 works.
Back to my original feature/bug report …
Selecting File->Print in LibreOffice brings up a “No default printer found” message which then leads to a Print page in which the only option is print to file.
StyledEdit and BePDF both bring up Page Setup windows in which the printer can be selected from a number of printers and will indeed print. So the printer integration in LibreOffice is outstanding and would be nice to have.
1 Like
I don’t think printing is implemented in LibreOffice. What you can do is to export your document into PDF and then print that via BePDF.
1 Like
“write is not possible” is not a permission granted or denied. And indeed, the error message you get when trying to write to /system is not “permission denied” (EPERM) but “read-only file system” (EROFS). Why do people then assume it is a permission problem? I don’t know. Why do you assume it should be represented as permissions? I also don’t know. Probably thinking in UNIX ways where that’s what you’d expect.
The distinction is there in the returned error, if one reads the error message carefully, they will see that the problem is not permissions.
2 Likes
Yes, that is my point. There is no way to represent “this is not applicable, what you are asking makes no sense”
I don’t want read only filesystem to be represented as a permission, I want there be a way to not have the write permission defined for files where this question does not make sense. But alas here we are 
The info is available, but it is not a permission. Not only you can find about it by trying to write a file, but also with statvfs, for example (ST_RDONLY in the flags).
Tracker already makes use of this info to show a grey background on these directories.
I’m not sure what else you want, a patch to ls to display this alongside the permissions for each file?
I would not hide the permissions, they are independant and still valid even if you’re currently looking at a readonly filesystem. It may still be useful to know if the file would be writable when mounting read/write. So, yes, they are currently not applicable, but the filesystem can be remounted differently. Of course, this is different for the special case of packagefs, but I don’t see what we could do about that. It could always put the write permission bits to 0, but then, it makes things look like it’s a permission problem, when it’s not.
Maybe we can make filesystems define a permission mask to define which permissions are available, and use that to hide/disable some of the permissions, for example in Tracker permissions window, and maybe even in ls. I guess this would be made available in get_fs_info or something similar?
We should probably reintroduce the lib:libstdc++ dependency in haikuporter. Otherwise new installs don’t get the updated gcc_syslibs.
4 Likes
Yes, I agree. I think I was the one to remove the warning, when instead HaikuPorter should just inject the dependency automatically.
There is obviously no problem with file permissions as far as I am concerned, it only arose as I was attempting to install -in error- a SMB implementation from an archive that was intended for reference only.
I can indeed print a LibreOffice document by exporting it and printing with BePDF or printing from Windows using SMB. The pdf and odt files go back and forth and are read without problem on both systems.
BePDF needs to have the pages filled in in Selected Pages, Print all pages gives a “Nothing to Print” error. Not a big problem once you know and it prints well.
I noted the lack of printing in Libre Office as a user request that the LibreOffice team could add to their todo list. Being able to print directly from LibreOffice would add a level of usability and elegance to the system that would make it more useful to unsophisticated users - once they had the printing sorted out of course.
Am very much in the user/testing camp here. Haiku is proving to be very stable and the LibreOffice (apart from the printing) works just as it should - with all the benefits of being on a superior, lean operating system.
The lack of printing is a bug in our qt port. It has nothing to do with libreoffice not supporting printing.
All errors you encountered in BePDF with the print dialog itself are likely OS level errors you can report on the bug tracker.
2 Likes