>> Greetings, dear AOO community.
>> Please note first that this message is not supposed to be flaimbait or
>> trolling of any kind.
>It is. Have a nice day.
Well it is not! I am Solaris user and sometime ago I tried to compile
in fact it should compile on Solaris
> > The hyphenation and other formatting information is on the Hunspell site
> > https://hunspell.github.io/
Actually this is the spelling assistant not the hyphenator. This module is
described in the following URL:
>Date: Wed, 29 Jun 2016 14:58:34 -0400
> From: lui...@gmail.com
> To: email@example.com
> Subject: Re: Spelling of Ancient Greek
Which means what? BTW, let me ask again: Where are the
hyphenation files and how they are created?
Suppose i would like to prepare a document in ancient Greek using AOO.
Naturally, I would like to enable hyphenation. To the best of my knowledge,
AOO is borrowing UTF-8 hyphenation patterns that are used in the TeX world.
If this is true, could you please let me know how can I create a
> yes, that's nice. But you shouldn't commit fixes without a possibility
> to test if it was good. Would you? ;-)
First I did this in the past. Please see
At that time I was sure the patches would find their way to source
> one problem of integrating patches is that you need to test them if the
> trunk builds are still OK or if some adjustments are necessary. However,
> AFAIK no developer has a Solaris machine under the desk and therefore
> it's not a good idea to commit fixes when you don't know what the
> > We have a number of old Solaris related build issues that
> > could use some testing.
> > https://bz.apache.org/ooo/show_bug.cgi?id=125361
> > https://bz.apache.org/ooo/show_bug.cgi?id=125362
> > https://bz.apache.org/ooo/show_bug.cgi?id=125364
Joerg Schmidt shared an interesting whitepaper from Microsoft White
Paper: OpenOffice / LibreOffice Evaluation Criteria on the dev-de list.
I found it interesting and thought it can be of interest for others here
We would need Apostolos to agree to contribute under the Apache
License 2.0 as well, since this is based on his work. (Or did he
already contribute the patches from his blog?) For example, it would
be fine if he just sent a note to the mailing list, pointing to the
blog posts, and saying
I have found a solution to this and other problems:
Of course the final binaries do nor run but this is something I will
resume working on this autumn.
: Απόστολος Συρόπουλος [mailto:asyropoulos...@hotmail.com]
Sent: Wednesday, June 25, 2014 12:24 AM
Subject: EXTERNAL: RE: NSS Module
I have found a solution to this and other problems:
strange because I can save files which are correct files. In my case the
problem is that the system complains that it cannot save while it actually
does. Also I can open and save doc files but I cannot open XML-based files.
I have recently built OpenOffice on Solaris. There are still some problems which
I try to sort out. One of them is that the panel with the File, Edit, etc menues
is empty and there are no icons on panel under this. In fact the whole upper
is empty. Could you please let me know which
, with some
Date: Fri, 7 Feb 2014 13:07:29 +0100
Subject: Re: Solaris GCC or Sun Studio?
On 07.02.2014 11:32, Απόστολος Συρόπουλος wrote:
As far it regards Solaris,I have noticed
As far it regards Solaris,I have noticed that the building scripts of OpenOffice
assume that one is building with Sun Studio. This compiler is a bit outdated
and of course GCC is available for most platforms. Since LibreOffice has
removed support for Sun Studio, I guess it would be a goof
+ // preserve potential 128bit stack alignment
I'm not sure whether the SPARCv9 ABI spec is relevant for your build
environment, but it mentions this 16byte stack alignment in  as
something new. Maybe the other changes may be relevant too to solve the
which configure options did you use?
Here is how I have configured OpenOffice:
$ export CONFIG_SHELL=/bin/bash
$ export LD_ALTEXEC=/opt/gnu/bin/gld
$ export ANT_HOME=/opt/gnu/ant/
$ export JAVA_HOME=/usr/jdk/jdk1.7.0
I have compiled all OpenOffice modules and now building stops as follows:
$ build --all:instsetoo_native
build -- version: 275224
Building module instsetoo_native
After a number of efforts I have finally managed to find the proper patch for
file bridges/source/cpp_uno/gcc3_solaris_intel/uno2cpp.cxx and so
to build a functional bridge for Solaris. Previously, I could not build
the testtools module but now they compile just fine. Here is the patch:
There is one person (Apostols Syropoulos) trying to compile the
latest version 4.0, but having trouble.
Then there are at least 2. I've tried and so far failed to compile 4.0.
[I'm using self built 3.4.1]
What compiler are you using? I used gcc 4.7.2 and now I have switched
Ouch! None of the exception stuff works in your new build. That is a
hard nut to crack...
I have recompiled the libraries used by uno with debugging info and I have
enabled this time
-fno-use-cxa-atexit. Now it dumps core and here is what I get with gdb:
In previous messages I reported my efforts to compile OpenOffice on
OpenSolaris. Since I thought
that certain things were not properly compiled, I recompiled everything and now
stops with the message that follows. Note that that I have compled everything
Wonderful. Getting there means that both the dmake and the gbuild
systems worked and the UNO bridge on this platform is doing alright.
These are all critical steps on new (or occassionally unmaintained)
platforms. With a bit of luck you should be able to build the remainder
of AOO and have it
I spooke too soon. After adding
the required library, that is, libgcc3_uno.so, was build
and compilation of i18npool finished successfully.
Google returns nothing about libg++_uno...
A library like that should be automatically built as one of the bridges
in main/bridge/source/cppu_uno/. In your case the gcc3_solaris_intel
bridge might be a good candidate but as the name says it probably builds
a libgcc3_uno.so instead of
Anyway, if we're lucky the problem is just a missing library or the failed
of a library. In that case the patch below might help you to analyze the
Indeed the problem is a missing library:
Thank you very much for the patch. Currently, I am trying to finish the build
I have applied the patch but I am getting some strange errors:
[ build CXX ] comphelper/source/misc/docpasswordhelper
In file included from
While compiling comphelper under Solaris, compilation stopped with the
following error message:
In file included from
I have solved the problem by adding the line
in file main/solver/410/unxsogi.pro/inc/comphelper/locale.hxx
Whether this is a valid solution or not, I have no idea...
Many of those projects have RTTI or C++ exceptions disabled, so problems
with typeinfo visibility may not show up there.
I have figured out that I need to use GCC with the Solaris linker to avoid all
these problems. BTW, the GCC people suggest people who use their
compiler on Solaris to
I have to admit that I have no clue about libxmlsec's detailed configure
requirements, so I'm afraid I can't help here much. But with the
knowledge that licrypto comes from openssl, with libxmlsec complaining
about the one openssl is providing maybe some changed linker or
Did it build with these configure options? Except for the minor nit that
--with-openssl is set twice, it looks good to me. The option has been
set as no and as /usr, but AFAIK the no should win.
The problem is that when configuring without the /usr value, the configure
I am still struggling... Now I was trying to build libxmlsec and the
configuration parameters did not give the expected result. I had
to enter manually the following command
./configure ADDCFLAGS= CPPFLAGS= --with-pic --disable-shared
I have downloaded the source code and I have reconfigured etc.
What I have observed so far is that there are a number of
utilities that consist of C and C++ source files. In all these cases,
the build script uses the C compile and so obviously it fails to build
the object files. For
After reading the reply by jan I. I decided to try again with GCC.
Now, compilation proceeds with no stupid problems as before.
BTW, main/soltools/adjustvisibility/adjustvisibility.c does not
compile with g++ but it compiles with CC so this is the only
thing I had to do manually. However, now
The quoted -features=rvalueref compiler option is probably caused by the
ARCH_FLAGS define in main/solenv/inc/unxsoli4.mk
I suggest to unquote it. But why did it work for others? Did dmake
unquote automatically at one time?
I have no idea :-( However, I have managed to go further and now
I dont know how you managed to get that directory.
I was manually building inside this folder...
the build system never add files or changes in the source directories. When
I look in
main/soltools/mkdepend on my system (after a complete build):
I have come to the conclusion that OpenOffice cannot be configured (at least
to compile with GNU g++ under Solaris. So I have tried Solaris Studio. Now I am
getting the following error message:
Building module soltools
As with any makefile, the whole chain is checked, and when you are in
soltools/mkdepend it check the object files against the source, and the exe
against the object files.
I work on changing the build system, and I often cheat the make system by
doing touch obj file, that way its not
Since there is no binary package for any version of Solaris x86, I am trying to
compile OpenOffice on OpenSolaris in the hope that the resulting binaries
will work in later versions.
I have downloaded the source code and I did the following:
$ export LD_ALTEXEC=/usr/bin/gld
normally you need to run autoconf before configure
ΟΚ I was just copying/pasting some info from my notes and of course
I forgot to mention that I did the autoconf and bootstrap steps. My bad.
it cannot find your compiler, maybe because you did not run bootstrap.
No I did run bootstrap,
Mail list logo