sot module build failures with recent gcc

[Don Lewis]

A FreeBSD user is trying to unbreak the ppc64 build and ran into an
issue with the sot module.  I dig into it pretty deeply and it looks to
me like a gcc bug.  It's reproducable in amd64.  It seems to affect
gcc10, gcc11, and gcc12 builds.  The build failure does not happen with
gcc9.

It is not limited to FreeBSD.  I get the same failure on Debian
bullseye:
 cc --version
cc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[ build LNK ] Library/libsot.so
/usr/bin/ld: 
/home/dl/aoo/openoffice/main/solver/4111/unxlngx6.pro/workdir/CxxObject/sot/source/sdstor/ucbstorage.o:
 in function `UCBStorage_Impl::Init()':
ucbstorage.cxx:(.text+0x72b4): undefined reference to `non-virtual thunk to 
cppu::WeakImplHelper1::acquire()'
collect2: error: ld returned 1 exit status


The problem appears to be that gcc is getting confused when compiling
line 1884 of ucbstorage.cxx.  It ends up trying to call the thunk to the
acquire() method of a non-existent class.  That thunk isn't defined, so
the linker bombs on the undefined symbol.

If I replace the-c flag with -S to get the assembler output:

Working version from gcc9:
.loc 2 1884 77 is_stmt 0 view .LVU7397
leaq48(%rsp), %rax
movq%rax, 16(%rsp)
movq16(%rsp), %rdi
leaq32(%rsp), %rax
movq%rax, 8(%rsp)
.LEHB557:
call_ZN10comphelper24getProcessServiceFactoryEv@PLT
.LVL3431:
.LEHE557:
.loc 2 1884 79 discriminator 1 view .LVU7398
movq48(%rsp), %r8


Broken version from newer gcc:
.loc 2 1884 77 view .LVU6791
leaq-176(%rbp), %r13
.LVL3116:
.LBB5707:
.LBB5706:
.LBB5705:
.loc 12 134 14 view .LVU6792
movq%rdi, -192(%rbp)
.loc 12 136 23 view .LVU6793
call_ZThn40_N4cppu15WeakImplHelper1IN3com3sun4star2io12XInputStreamE
E7acquireEv

.loc 12 xxx xxx refers to the Reference() template in
com/sun/star/uno/Reference.hxx lines 134-136, which calls acquire().


It would be nice if someone could put together a trimmed test case and
file a gcc bug report.

I don't have any good ideas about patching the source to work around the
bug while waiting for a gcc fix.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: FreeBSD port status

[Don Lewis]

On 11 Mar, Don Lewis wrote:
> I've had some time in the last couple of weeks to work on the FreeBSD
> port.  I was able to get 4.1.14 to build and updated the FreeBSD port to
> that version.  I committed the upgrade to the main branch of the FreeBSD
> ports tree on March 8. I merged the change to the current ports
> quarterly branch a short while ago, so mainstream users should see the
> new binary packages show up in the next several days.
> 
> For various reasons, I switched the FreeBSD port back to the bundled
> boost.  The FreeBSD port uses -std=gnu++98 mode to compile our code. One
> of the things I found is that even in that mode, our bundled boost tries
> to use some c++11 features, and recent versions of clang treat that as
> an error.  This can be fixed with a trivial patch, which I added to the
> FreeBSD port.  I plan to commit this fix to our source tree in the near
> future.
> 
> Another FreeBSD user found that our build is fragile, and can be broken
> if the build environment is not clean.  The problem is that the order of
> the directories in our include path is not safe.  We put the include
> directories for external dependencies like the libs for gtk ahead of
> internal and solver directories.  If one of the system include
> directories is /usr/local/include, then the build can pick up the system
> boost if it is installed on the machine.  The FreeBSD boost port has
> issues with gnu++98 mode.  This breaks both gbuild and dmake module
> builds of 4.1.x.  Gbuild is mostly fixed in trunk and 4.2.x, and on
> those branches so much has been converted to gbuild that I haven't seen
> the problem.  The modules left using dmake don't seem to both use boost
> and have problematic external dependencies.  I have patches for both the
> gbuild and dmake stuff, but the gbuild fix is only for the FreeBSD
> platform.  The dmake framework patch is generic, but I've only tested it
> on FreeBSD.
> 
> The FreeBSD port broke some time ago because of errors in some of the
> API comments in the xmerge java source.  We've fixed these in trunk and
> 4.2.x, but they are still broken in 4.1.x.  They have been flagged as
> errors during the build for a very long time, but it was only sometime
> last summer when they started getting treated as a fatal error by the
> FreeBSD build.  They are still flagged as errors, but they are no longer
> fatal. I have no idea what caused the behavior to change in either
> direction.
> 
> I also experimented a bit with c++11 mode and discovered that recent
> versions of clang are much less forgiving of questionable code in that
> mode as compared to the older versions of clang that I tried several
> years ago.  I ran into many things that broke the build:
> 
>   reinterpret_cast< some_type*>(NULL) is a compilation error.  These are
>   trivial to fix by switching to static_cast, but the modules where
>   these occur seem to use reinterpret_cast excessively.  I would be
>   surpised if there were more than a handful of locations in our code
>   where reinterpret_cast is the right choice.
> 
>   Constructors where the width of the initialization data is wider than
>   the width of the member being initialized break the build.  Recent
>   clang does not want to automatically narrow the data and wants an
>   explicit cast to be used.  The casts are easy to add, but the compiler
>   is pointing out places in the code where there might be exploitable
>   integer overflows.  Perhaps the member should be widened so that an
>   overflow isn't possible, or pehaps an assert should be added or an
>   exception thrown on overflow.

It looks like Damjan fixed a bunch of this stuff back in January in
a72d41dcd002e8c9b3d75696f0625302690e2d65 on trunk.  I was working with
AOO42X, which is why I didn't see the fixes.  The narrowing fixes were
done by adding casts, so any integer overflow issues are ignored, which
is the status quo when compiled without the casts.

>   The canvas, dbaccess, reportdesign, and slideshow modules use
>   iterators such a ::std::find_if and ::std::count_if to repeatedly call
>   functions using ::boost::bind whose args are all supposed to be
>   references.  In some instances the code uses ::boost::cref() to
>   convert expressions into references.  Recent clang objects if the
>   argument to ::boost::cref() is not an lvalue.  A handful are
>   trivivally fixable, but most are not.  In some cases it is not obvious
>   if the value of the expression shouldn't be changing due to the
>   actions of the function in the previous iteration, so calculating the
>   expression once, storing the result in a temporary location and
>   passing a reference to that location could result in stale data being
>   used. In another case, a method is called that constructs a s

Re: FreeBSD port status

[Don Lewis]

FYI, I do maintain a FreeBSD port of AOO42X and periodically update it
with newer snaphots of our code.  FreeBSD users can install binary
packages of it.  It was broken for quite a while, but I've gotten it
working again.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: FreeBSD port status

[Don Lewis]

On 12 Mar, Matthias Seidel wrote:
> Hi Don,
> 
> thank you for your detailed report!
> 
> Most of the technical things are above my understanding. ;-)

Some of it is beyond mine, in particular the iterator stuff.  I'm also very
unfamiliar with that part of the code and have no idea how to test it
properly.
 
> But what I saw in the 4.1.14 development process was, that we have a big
> amount of code changes in trunk/AOO42X, that never got backported/released.

Yes.  The code and build framework in trunk/AOO42X is much better than
AOO41X.

> Normally, we should release it with AOO 4.2.0, but since that process is
> stagnating over years I would prefer to cherry-pick code into AOO41X
> (where possible).
> 
> I already made some commits (mostly optical changes):
> 
> https://github.com/apache/openoffice/compare/AOO4114-GA...AOO41X
> 
> And maybe we can get AOO42X in a stable condition in parallel?

Trying to cherry-pick a lot of this stuff back into AOO41X would be a
lot of work.  There are a lot of commits that would need to be
inventoried.  There are also a lot of interdependencies, so the
cherry-picks would have to be done in the right order.  Then there would
still likely be a bunch of merge conflicts that would need manual
intervention to resolve, with thie possibility of introducing bugs.

I see this as putting a lot of effort into something that is ultimately
a dead end.  I think it would be better in the long run to get 4.2.0 out
the door.

Something else that should be higher on the priority list is migrating
to a more modern Windows toolchain that has support for modern C.  We
spent too much effort on working around the limitations of our current
Windows compiler when importing new versions of bundled third-party
code.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

FreeBSD port status

[Don Lewis]

I've had some time in the last couple of weeks to work on the FreeBSD
port.  I was able to get 4.1.14 to build and updated the FreeBSD port to
that version.  I committed the upgrade to the main branch of the FreeBSD
ports tree on March 8. I merged the change to the current ports
quarterly branch a short while ago, so mainstream users should see the
new binary packages show up in the next several days.

For various reasons, I switched the FreeBSD port back to the bundled
boost.  The FreeBSD port uses -std=gnu++98 mode to compile our code. One
of the things I found is that even in that mode, our bundled boost tries
to use some c++11 features, and recent versions of clang treat that as
an error.  This can be fixed with a trivial patch, which I added to the
FreeBSD port.  I plan to commit this fix to our source tree in the near
future.

Another FreeBSD user found that our build is fragile, and can be broken
if the build environment is not clean.  The problem is that the order of
the directories in our include path is not safe.  We put the include
directories for external dependencies like the libs for gtk ahead of
internal and solver directories.  If one of the system include
directories is /usr/local/include, then the build can pick up the system
boost if it is installed on the machine.  The FreeBSD boost port has
issues with gnu++98 mode.  This breaks both gbuild and dmake module
builds of 4.1.x.  Gbuild is mostly fixed in trunk and 4.2.x, and on
those branches so much has been converted to gbuild that I haven't seen
the problem.  The modules left using dmake don't seem to both use boost
and have problematic external dependencies.  I have patches for both the
gbuild and dmake stuff, but the gbuild fix is only for the FreeBSD
platform.  The dmake framework patch is generic, but I've only tested it
on FreeBSD.

The FreeBSD port broke some time ago because of errors in some of the
API comments in the xmerge java source.  We've fixed these in trunk and
4.2.x, but they are still broken in 4.1.x.  They have been flagged as
errors during the build for a very long time, but it was only sometime
last summer when they started getting treated as a fatal error by the
FreeBSD build.  They are still flagged as errors, but they are no longer
fatal. I have no idea what caused the behavior to change in either
direction.

I also experimented a bit with c++11 mode and discovered that recent
versions of clang are much less forgiving of questionable code in that
mode as compared to the older versions of clang that I tried several
years ago.  I ran into many things that broke the build:

  reinterpret_cast< some_type*>(NULL) is a compilation error.  These are
  trivial to fix by switching to static_cast, but the modules where
  these occur seem to use reinterpret_cast excessively.  I would be
  surpised if there were more than a handful of locations in our code
  where reinterpret_cast is the right choice.

  Constructors where the width of the initialization data is wider than
  the width of the member being initialized break the build.  Recent
  clang does not want to automatically narrow the data and wants an
  explicit cast to be used.  The casts are easy to add, but the compiler
  is pointing out places in the code where there might be exploitable
  integer overflows.  Perhaps the member should be widened so that an
  overflow isn't possible, or pehaps an assert should be added or an
  exception thrown on overflow.

  The canvas, dbaccess, reportdesign, and slideshow modules use
  iterators such a ::std::find_if and ::std::count_if to repeatedly call
  functions using ::boost::bind whose args are all supposed to be
  references.  In some instances the code uses ::boost::cref() to
  convert expressions into references.  Recent clang objects if the
  argument to ::boost::cref() is not an lvalue.  A handful are
  trivivally fixable, but most are not.  In some cases it is not obvious
  if the value of the expression shouldn't be changing due to the
  actions of the function in the previous iteration, so calculating the
  expression once, storing the result in a temporary location and
  passing a reference to that location could result in stale data being
  used. In another case, a method is called that constructs a struct and
  fills it with a bunch of data from multiple class member values, and
  the struct is returned, a reference to that struct is created and that
  reference passed to the function.  It isn't obvious to me that some of
  those class members are not modified by the function, so the stale
  data issue is there, but also the memory for the struct is leaked
  because it is never destroyed.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: WebDAV module ported from serf to curl; curl using openssl and zlib (was: Re: Openssl, serf and curl)

[Don Lewis]

On 26 Apr, Damjan Jovanovic wrote:
> On Mon, Nov 15, 2021 at 9:57 PM Jim Jagielski  wrote:
> 
>> I'm gonna look into the serf->(lib)curl option... Since we don't use any
>> of the fancy features of serf, I'm thinking that the easy option might be
>> best
> 
> 
> 
> Hi
> 
> I've ported our WebDAV content provider module from Serf to Curl.
> 
> While it ended well, and several other bugs were found and fixed, it
> definitely wasn't the "easy option" Jim ;). Starting with conservative
> changes, it ended up needing total restructuring, and became more of a
> rewrite. The crashes were frequent and hung connections many, and I had to
> read up on the HTTP protocol, and read Curl and Serf's source code, but
> eventually I prevailed, and a clean elegant stable Curl WebDAV module
> emerged.
> 
> The huge patch is attached for anyone wishing to review and test. Unless
> there are major objections, I'll push it in a couple of days.
> 
> STATUS
> 
> It builds and works well on FreeBSD and Windows.
> 
> Most of the code was reused, and all the operations and semantics
> previously present with Serf, should have been preserved.
> 
> Browsing WebDAV files and directories, loading files, overwriting them
> ("Save"), creating them ("Save As"), renaming and deleting them, all works.
> 
> HTTP and HTTPS proxies work. Unlike Serf, Curl could also support SOCKS
> proxies (with minimal further changes), but AOO lacks that setting in the
> proxy UI and configuration.
> 
> Authentication works, both to the destination server and to the proxy
> server. I've successfully tested Basic and Digest authentication. Curl
> supports every authentication method Serf does and more.
> 
> HTTPS works, with a custom certificate verification function, using our own
> certificate store from NSS and its API (like the Serf code used). A bug was
> discovered (which is in the Serf implementation too) where self-signed
> certificates were being unconditionally rejected; apparently NSS wants to
> see that a copy of that certificate  in its certificate chain parameter
> too. Now they work, and the user gets prompted to allow access.
> 
> HTTPS and authentication can be used together on the same connection and
> work well, both bringing up their UI dialogs as needed.
> 
> A bug was fixed where when username and password were both present in the
> URL (dav://user:pass@host/path), the code was trying to split them at the
> "@" instead of ":".
> 
> Unnecessary base64 encoding and decoding was removed, when importing the
> TLS connection's certificates into our XSecurityEnvironment. They now come
> in directly as ASN.1 DER, and still work.
> 
> The code was greatly restructured and cleaned up, as Curl's API is
> synchronous and blocking, with parameters set in advance instead of through
> many callbacks, which has allowed using short clear methods, and clean
> separation between the session and request classes. The WebDAV content
> provider has shrunk from 35 to 21 C++ files, 43 to 29 header files, and
> 19129 to 15991 lines of code. With WebDAV methods centralized and
> refactored into only 10-20 lines of code each, instead of scattered across
> 4 files, it is much more understandable and maintainable now.
> 
> Curl is vastly more portable than Serf. We should build easily now even on
> OS/2. We can remain with existing build tools instead of needing scons or
> cmake just to build Serf.
> 
> 3 now unused dependencies were removed: apr, apr-util, and serf. Serf isn't
> so bad. APR's pool idea is an ingenious way of doing resource management in
> C. However Curl has excellent documentation, guides, examples, and detailed
> explanations and even example code for each setting, while Serf has no
> documentation. Serf might be worth it in a project that already uses APR a
> lot, but we don't.
> 
> Instead of the historical, crippled forms of logging like OSL_TRACE(),
> which don't appear in release builds, I've made it use the newer
> com.sun.star.logging UNO component (wrapped in comphelper::EventLogger),
> which was inspired by java.util.logging, with configurable verbosity
> levels, handlers (file and console) and output formats (plain, csv), and
> importantly, which produces output in release builds too. I've also made it
> so that on LogLevel::FINEST, Curl's verbose mode is enabled and Curl's
> debug output is also logged through us, with descriptions of what Curl is
> doing, and logs of all HTTP traffic including headers and bodies, before
> encryption and after decryption in the case of HTTPS, giving us tremendous
> detail that can be used for troubleshooting problems.
> 
> CURL CHANGED TO USE OPENSSL AND ZLIB
> 
> Curl only supports the custom TLS certificate verification function we use
> (the CURLOPT_SSL_CTX_FUNCTION option) when built with OpenSSL, wolfSSL or
> mbedTLS providers. We currently use schannel on Windows instead, which had
> to be changed. I also made it use zlib, which generally helps, and WebDAV
> uses XML which is very verbose and 

Re: [VOTE] Release AOO 4.1.12-RC1 as GA

[Don Lewis]

On 13 Apr, Jim Jagielski wrote:
> I am calling a VOTE on releasing the source and complimentary community 
> builds of
> Apache OpenOffice 4.1.12-RC1 as GA.
> 
> These artifacts can be found at:
> 
> https://dist.apache.org/repos/dist/dev/openoffice/4.1.12-RC1/
> 
> Please cast your vote:
> 
The Release Candidate is good for production/GA:

[X] yes / +1

[ ] no / -1

My vote is based on

[ ] binding (member of PMC)

[X] I have built and tested the RC from source on platform [FreeBSD]

[ ] I have tested the binary RC on platform [ ]

I tested the source tarball checksum.

Opening, editing, saving existing calc and writer docs works.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: epm 5 not compiling on FreeBSD 13

[Don Lewis]

BTW, FreeBSD doesn't even use epm.  It should be possible to patch
configure.ac to avoid looking for it.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [GitHub] [openoffice] ardovm edited a comment on pull request #133: graphite: remove the -Werror option from debug builds

[Don Lewis]

On 20 Jun, Pedro Lino wrote:
> Hi Arrigo, all
> 
> Development seems to be quite live at
> https://github.com/silnrsi/graphite

We are using SIL Graphite, http://silgraphite.sourceforge.net/

Looking at the Graphite technical overview page mentioned here:
  https://github.com/silnrsi/graphite/blob/master/README.md
(https://scripts.sil.org/cms/scripts/page.php?site_id=projects_id=graphite_techAbout)
under "Graphite engine implementations":

  There are two existing implementations of the Graphite engine. The
  original engine is packaged under the name "SilGraphite"; the initial
  implementation was done in 2000. The Graphite2 engine implementation
  began in 2010.

  The  SilGraphite engine is currently used by OpenOffice, XeTeX,
  FieldWorks, and WorldPad. It includes some features not included in
  Graphite2, but is considerably slower.  Graphite2 represents a
  significant (10x) optimization in terms of speed and greatly improved
  robustness, but does not include a few features such a ligature
  component handling and cross-line-boundary contextualization.
  Graphite2 is used by LibreOffice and Firefox.

  The two engines support different APIs. The Graphite2 API was
  specifically developed to be more compatible with the approach to text
  layout used by most commercial software. See the application
  development page for API documentation.

Graphite2 would be better, is currently supported, and Libreoffice
switched to it quite a while ago, but it is not a drop-in replacement.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: building with gcc 10 and external (system) boost

[Don Lewis]

On 20 Jun, Yury Tarasievich wrote:
> Hello Peter,
> 
> You are right on both issues, of course.
> 
> To be fair, on your (1), I didn't touch that 
> variable check, I just brute-forced the C++11 
> mode of compilation.
> 
> Which leads to your (2), but thing is, modern 
> boost sort of requires C++11. Might be other 
> external modules do, too.
> Might that switch to C++11 be overdue?
> 
> What I consider the nicest result (beyond the 
> 'fact of the pudding') is seeing that the C++11 
> build is achievable with very minimal changes to 
> the source, which wouldn't (shouldn't?) reflect 
> on builds with older versions of GCC.

I think that we still need to do release builds of 4.1.x on CentOS 5. Is
it's version of gcc new enough?

Same question about the ancient toolchain we use for Windows builds.

Since we don't use any of the boost libraries, only the include files,
there's not real penalty in using the bundled boost other than the time
it takes to download and unpack.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: svn commit: r1890844 - /openoffice/devtools/build-scripts/4.1.10/wntmsci/build_aoo32bit_on_mingw. sh

[Don Lewis]

On 16 Jun, ard...@apache.org wrote:
> Author: ardovm
> Date: Wed Jun 16 19:07:44 2021
> New Revision: 1890844
> 
> URL: http://svn.apache.org/viewvc?rev=1890844=rev
> Log:
> Build script for AOO 4.1.10 under Mingw
> 
> Better late than never... could be used as a template for the future

I thought our Mingw support had rotted.  It hasn't been used in ages.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [VOTE] Release AOO 4.1.10-RC2 as GA

[Don Lewis]

The Release Candidate is good for production/GA:

[X] yes / +1

[ ] no / -1

My vote is based on

[ ] binding (member of PMC)

[X] I have built and tested the RC from source on platform [FreeBSD]

[ ] I have tested the binary RC on platform [ ]


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Apache OpenOffice 4.1.10-RC2

[Don Lewis]

On 20 Apr, Jim Jagielski wrote:
> Before we call a vote, I'd like to ask as many people as possible to give the 
> 2nd release candidate of AOO 4.1.10 a good, solid test.
> 
> The source files and complimentary community builds for this RC can be found 
> at:
> 
> https://dist.apache.org/repos/dist/dev/openoffice/4.1.10-RC2/

Looking good so far on FreeBSD.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Fwd: [libexpat/libexpat] Release R_2_3_0 - 2.3.0

[Don Lewis]

On 25 Mar, Matthias Seidel wrote:
> Hi all,
> 
>> #422 #426 #447 Windows: Drop support for Visual Studio <=14.0/2015
> 
> Seems, we are out of look here due to the ancient compiler we still use
> on Windows...

Same with nss.  I suspect lack of C99 support is the issue.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [VOTE] Release AOO 4.1.9-RC1 as GA

[Don Lewis]

 [X] yes / +1

 [ ] no / -1

My vote is based on

 [ ] binding (member of PMC)

 [X] I have built and tested the RC from source on platform [FreeBSD]

 [ ] I have tested the binary RC on platform [ ]

On 18 Jan, Jim Jagielski wrote:
> I am calling a VOTE on releasing the source and complimentary community 
> builds of
> Apache OpenOffice 4.1.9-RC1 as GA.
> 
> These artifacts can be found at:
> 
>https://dist.apache.org/repos/dist/dev/openoffice/4.1.9-RC1/
> 
> Please cast your vote:
> 
> The Release Candidate is good for production/GA:
> 
>  [ ] yes / +1
> 
>  [ ] no / -1
> 
> My vote is based on
> 
>  [ ] binding (member of PMC)
> 
>  [ ] I have built and tested the RC from source on platform [ ]
> 
>  [ ] I have tested the binary RC on platform [ ]
> 
> This vote will be open for 96hrs instead of the normal 72hrs to
> accommodate the US Holiday.
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO 4.1.9 Info - bug 127952

[Don Lewis]

On  6 Jan, Jim Jagielski wrote:
> 
> 
>> On Jan 6, 2021, at 9:19 AM, Arrigo Marchiori  wrote:
>> 
>> Hello All,
>> 
>> 
>> - My own build of trunk on Linux can open the file.
>> 
>> Do you think that this is worth more investigation before releasing
>> 4.1.9?
>> 
> 
> AFAICT, it is not a regression (trunk and 4.1.x are very different)... So I 
> don't
> think it should hold off 4.1.9-RC1 IMO

Agreed.  Who knows how long this would take to understand, fix, and
test.   In the meantime, there are a lot of Big Sur users waiting on
4.1.9.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: issue with dmake clean

[Don Lewis]

On 16 Dec, Arrigo Marchiori wrote:
> Hello all,
> 
> On Tue, Dec 15, 2020 at 05:56:48PM -0500, Carl Marcum wrote:
> 
>> On 12/15/20 3:37 PM, Peter Kovacs wrote:
>> > 
>> > On 15.12.20 20:14, Jim Jagielski wrote:
>> > > 
>> > > > On Dec 15, 2020, at 12:57 PM, Matthias Seidel
>> > > >  wrote:
>> > > > 
>> > > > Hi Carl,
>> > > > 
>> > > > Am 13.12.20 um 23:43 schrieb Carl Marcum:
>> > > > > Hi Matthias,
>> > > > > 
>> > > > > On 12/13/20 4:29 PM, Matthias Seidel wrote:
>> > > > > > Hi Carl,
>> > > > > > 
>> > > > > > Am 13.12.20 um 19:02 schrieb Carl Marcum:
>> > > > > > > Hi all,
>> > > > > > > 
>> > > > > > > Just ran into something.
>> > > > > > > 
>> > > > > > > I ran 'dmake clean' from main probably without having ran source
>> > > > > > >  and it removed all of my directories under 
>> > > > > > > main.
>> > > > > > Tried to do that on Windows (Cygwin64), went into main,
>> > > > > > did "autoconf",
>> > > > > > "dmake clean":
>> > > > > > 
>> > > > > > $ dmake clean
>> > > > > > -bash: dmake: command not found
>> > > > > > 
>> > > > > > Only after "source winenv.set.sh" it did clean up what it should...
>> > > > > It could be because I have a built and installed dmake on my system.
>> > > > > 
>> > > > > Thanks for checking!
>> > > > If an installed dmake does have this consequence we should have
>> > > > a closer
>> > > > look at it...
>> > > > 
>> > > It must be getting those commands from a makefile somewhere
>> > > though... dmake itself has no concept of 'clean' independent of what
>> > > a makefile tells it it is AFAIK
>> > 
>> > there is a makefile on that level. However I think it is for make and
>> > not for dmake. At least when I want to reset the build for sure I do a
>> > dmake clean (from instsetoo_native)first, followed by a make clean
>> > (main).
>> > 
>> > And the make clean has this rm command and removes all sorts of stuff.
>> > Could it be that if you execute dmake clean on main folder will let
>> > dmake read the make file ment for gnumake?
> [...]
>> I've had it happen twice now and it's a pain when it happens but probably
>> not dmake's fault.
> 
> If main/makefile.mk is used by dmake, then that could be the culprit.
> 
> The clean target does:
> 
>> clean .PHONY:
>> -rm -rf */$(INPATH)
> [... the rest is uninportant ...]
> 
> The INPATH variable is set by the Env.sh script
> If the env.sh script is not set, then the command is interpreted as:
> rm -rf */
> 
> I don't know dmake, but if it was GNU Make a possible fix would be
> something like:
> 
>> clean .PHONY:
>> if [ -z "$(INPATH)" ]; then echo "Environment not set!"; exit 1; fi
>> -rm -rf */$(INPATH)
> [... the rest same as above ...]

Something like that is what I would recommend.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Updates to ./configure(.ac)

[Don Lewis]

On  9 Dec, Jim Jagielski wrote:
> 
> 
>> On Dec 9, 2020, at 9:56 AM, Mechtilde  wrote:
>> 
>> Hello Jim,
>> 
>>> 
>>> So I was thinking we just have these 3:
>>> 
>>> --with-epm
>>> --with-dmake
>>> --with-beanshell
>> 
>> I want to differ whether we build with system version or with separate
>> version like in ext_sources.
> 
> Can you provide an example?
> 
> For example, say we want to use the system version of dmake... We could do 
> either
> 
>   --with-dmake
> 
> which would look in the user's $PATH for dmake and use that one; or they 
> could do
> 
>   --with-dmake=/opt/local/bin/dmake
> 
> which would use the system version located in /opt/local/bin
> 
> If instead, one used:
> 
>   
> --with-dmake=https://github.com/jimjag/dmake/archive/v4.13.1/dmake-4.13.1.tar.gz
> 
> It would download that distro and build and not use any local/system versions.
> 
> Does that make it more clear?

For dmake, we always need it, so --without-dmake would neve make sense.
For the path vs. url cases, we would need to add code to parse the
argument to decide whether we need need to do a download and build and
point the path at the result of the build, or whether we can just use
the argument as a full path.  In addition to https, the URL could
theoretically be ftp or a local file.  This touches both configure and
bootstrap.

I haven't looked at the beanshell stuff enough to comment.





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Configure missing gtk-plugin

[Don Lewis]

On  7 Dec, Peter Kovacs wrote:
> Hello all,
> 
> I haave an issue with configuring I am unfammiliar with.
> 
> configure: error: requirements to build the gtk-plugin not met. Use
> --disable-gtk or install the missing packages
> 
> What does this mean? I did not find this in any package.
> 
> I installed gtk2 and gst-plugin-gtk (which are the package names that 
> are given by arch.)
> 
> And I do not see any different requiremments in the guide.

configure is looking for:
gtk+-2.0 >= 2.4
gdk-pixbuf-xlib-2.0 >= 2.2
gthread-2.0

What OS are you building on?


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Help w/ bt

[Don Lewis]

On  2 Dec, Jim Jagielski wrote:
> Building --enable-debug is causing a weird issue...
> 
> ../unxmaccx.pro/bin/makedepend: error:  got signal 4
> dmake:  Error code 1, while making '../unxmaccx.pro/obj/checkdll.obj'
> dmake:  '../unxmaccx.pro/obj/checkdll.obj' removed.
> 
> I'm not sure if this is macOS specific or whether or not doing so
> breaks on other platforms as well... anyone know before I spin up
> another VM and test?

I don't think I've used it recently, but it has worked in the past on
linux and FreeBSD.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [openoffice] branch trunk updated: Huge updates to macOS UNO bridges, based on FreeBSD and Linux.

[Don Lewis]

On  1 Dec, j...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> jim pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/openoffice.git
> 
> 
> The following commit(s) were added to refs/heads/trunk by this push:
>  new d73dd1d  Huge updates to macOS UNO bridges, based on FreeBSD and 
> Linux.
> d73dd1d is described below
> 
> commit d73dd1d32e12ca3b96b7bbfff854b742992ff915
> Author: Jim Jagielski 
> AuthorDate: Tue Dec 1 16:59:54 2020 -0500
> 
> Huge updates to macOS UNO bridges, based on FreeBSD and Linux.
> 
 
> diff --git a/main/bridges/source/cpp_uno/gcc3_freebsd_x86-64/except.cxx 
> b/main/bridges/source/cpp_uno/gcc3_freebsd_x86-64/except.cxx
> index 7902bd9..bfe18db 100644
> --- a/main/bridges/source/cpp_uno/gcc3_freebsd_x86-64/except.cxx
> +++ b/main/bridges/source/cpp_uno/gcc3_freebsd_x86-64/except.cxx
> @@ -187,7 +187,7 @@ type_info * RTTI::getRTTI( 
> typelib_CompoundTypeDescription *pTypeDescr ) SAL_THR
>  type_info * base_rtti = getRTTI(
>  (typelib_CompoundTypeDescription 
> *)pTypeDescr->pBaseTypeDescription );
>  rtti = new __si_class_type_info(
> -strdup( rttiName ), static_cast<__class_type_info 
> *>(base_rtti) );
> +strdup( rttiName ), (__class_type_info *)base_rtti );
>  }
>  else
>  {

What is the reason for this change?  static_cast is the more correct C++
way as opposed to a C-style cast.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [OPINION VOTE] CentOS7 or Ubuntu 14.04

[Don Lewis]

On 10 Nov, Jim Jagielski wrote:
> CentOS7: glibc 2.17
> Ubuntu 14.04: glibc 2.19 
> 
> Since CentOS7 emulates the "super stable" worldview of RHEL, the
> CentOS7 version will likely always be the older one.

In that case I think a Ubuntu build is unlikely to run on CentOS 7.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [OPINION VOTE] CentOS7 or Ubuntu 14.04

[Don Lewis]

On 10 Nov, Jim Jagielski wrote:
> History: For previous AOO releases (up to 4.1.8), we have used
>  CentOS5 as our build environ for our community builds.
>  As of 4.2.x, this is no longer an option. Instead, we
>  baselined CentOS7 (mainly due to gstreamer 1.0).
> 
> Discussion: The issue w/ CentOS7 is that the 32bit version is
> not officially supported. This means that for our
> 32bit builds we are using an unsupported platform.
> Instead of using CentOS7, we could instead baseline
> Ubuntu 14.04, which is both 64 and 32bit as well as
> both under LTS.
> 
> So the question is: CentOS7 or Ubuntu 14.04?

What are the gcc/glibc versions of both?  If we build on the distro with
the newer versions, the result won't run on the older version.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

upgrade notifications once we release 4.2.0

[Don Lewis]

For 4.2.0, we are talking about building on CentOS 7.  Therefore some of
platforms that we currently support won't support 4.2.0, in particular
CentOS 5, which is currently EOL and CentOS 6, which is still supported
upstream, at least for now the last time I looked.

If a user is running on an older platform, it would seem to be unhelpful
for them to be notified about 4.2.x releases, but we would want them to
see a possible 4.1.9 release.  Users on newer platforms should be
steered towards 4.2.x.

Thoughts?


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: update NSS libraries

[Don Lewis]

On  7 Nov, John D'Orazio wrote:
> Hello all, ss I continue building and debugging the next release of my
> Writer add-on, in which I'm attempting to include the *Chrome Embedded
> Framework* in it's Java flavoured build (I'm using the builds from this
> release
> 
> ), I've stumbled upon the following situation in my Linux build:
> 
> The Chrome Embedded Framework is requiring a *libnss3.so* and
> *libnssutil3.so* version of at least *3.22*, however OpenOffice also
> utilizes these libraries and is packaging version *3.14*. Since the
> OpenOffice libraries are the first ones picked up (I believe from the
> *LD_LIBRARY_PATH* environment variable or similar), it is preventing my
> add-on from building, complaining that CEF needs at least version 3.22. As
> a test, I went and backed up the *libnss3.so* and *libnssutil3.so* found in*
> /opt/openoffice4/program/* , and I copied my system's libraries to that
> same folder. My system's libraries are at version *3.49* . After this I was
> able to build the add-on and debug->run in OpenOffice, and at least at
> first sight I didn't see any adverse effects in OpenOffice from the newer
> NSS libraries.
> 
> Would it be feasible to update the NSS libraries in a next release of
> OpenOffice, say 4.1.9? Carl Marcum was just confirming that in the current
> 4.1.8 release the packaged libraries are in fact at version 3.14.

4.1.8 was upgraded to nss 3.25.  This pull request
https://github.com/apache/openoffice/pull/100 will get us to 3.39, but it
has not even been merged to trunk because we haven't had the resources
to test it because of the push to get AOO 4.1.8 out the door.  It should
be possible to get it into 4.1.9.

It would be nice to get fully up to date, but newer versions of nss use
a lot of C99, which is not supported by the ancient Visual C++ that we
use.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [VOTE] Release AOO 4.1.8-RC2 as GA

[Don Lewis]

On  2 Nov, Jim Jagielski wrote:
> I am calling a VOTE on releasing the source and complimentary community 
> builds of
> Apache OpenOffice 4.1.8-RC3 as GA.
> 
> These artifacts can be found at:
> 
> https://dist.apache.org/repos/dist/dev/openoffice/4.1.8-RC3/
> 
> Please cast your vote:
 
The Release Candidate is good for production/GA:

  [X] yes / +1

  [ ] no / -1

My vote is based on

  [ ] binding (member of PMC)

  [X] I have built and tested the RC from source on platform [CentOS 5, Debian 
9, FreeBSD 10]

  [ ] I have tested the binary RC on platform [ ]


Notes:
  I did a 32-bit build on CentOS 5 and tested that build on CentOS 5 and
  Ubuntu 16.

  I did a 64-bit build on Debian 9 and tested that build on Debian 9

  I did 32-bit and 64-bit builds on FreeBSD 11, 12, and 13.  I tested
  the 64-bit FreeBSD 11 build.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.1.8-RC3

[Don Lewis]

On  1 Nov, Pedro Lino wrote:
> Hi Don
> 
>> On 11/01/2020 5:55 PM Don Lewis  wrote:
> 
>> What about AOO418?
> 
> Apparently this issue only happened with my own build. It does not occur with 
> the official 418 RC3 build compiled by Jim
> (I mentioned this in a previous email)
> 
> So there is no need to worry about branch 418, only 42x and trunk.
> 
> I will test this tomorrow and report back.

I think it depends on the configure options.  Either of this will cause
the gconf library to end up in the core01 package:
  --enable-gconf --enable-gnome-vfs --enable-lockdown
  --enable-gconf --enable-gio

i think --enable-gconf and --enable-gnome-vfs are defaulted to on in
AOO418, but --enable-lockdown is not.  I haven't looked at the official
build script to see what options are set there.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.1.8-RC3

[Don Lewis]

On  1 Nov, Matthias Seidel wrote:
> Hi Don,
> 
> Thanks for the update!
> 
> @Pedro: Does that solve the problem? If yes, could you set the issue to
> "RESOLVED"?

What about AOO418?


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.1.8-RC3

[Don Lewis]

On 31 Oct, Matthias Seidel wrote:
> Hi Don,
> 
> Am 31.10.20 um 13:58 schrieb Don Lewis:
>> On 30 Oct, Pedro Lino wrote:
>>> Just recompiled AOO 4.1.8 on another Ubuntu 18.04.5 x64 without issues.
>>>
>>> Installing 4.1.8 over 4.1.7 end with error reported 2 years ago
>>>
>>> https://bz.apache.org/ooo/show_bug.cgi?id=127774
>> I just updated that ticket with some new information.  It is possible to
>> debug this by rebuilding just the scp2 module and looking at
>> scp2/unxlngx6.pro/bin/osl/setup_osl.ins
> 
> It would be great if we could work that out, since this is a release
> blocker for 4.2.0.

I think I have the immediate problem fixed, but there are still quite a
few mismatches between the gids defined and the gids referenced by
modules.

When building setup_osl.ins, these gids are referenced, but are not
defined:
gid_File_Share_Config_Sofficecfg_Dbubrowser_Menubar_Xml
gid_File_Extra_Urlmore_Math
gid_File_Tmp_Userinstall_Pocketpcword_Inf
gid_File_Exe_Regdeinstall
gid_File_Jar_Sandbox
gid_Brand_File_Share_Xdg_Extension
gid_File_Lib_Dfa
gid_File_Jar_Activation
gid_File_Exe_Nsplugin
gid_File_Lib_Policy_Cli_Cppuhelper_Config
gid_File_Lib_Wpft
gid_File_Lib_Hhc_Word
gid_File_Res_Tfu
gid_File_Exe_Uno
gid_File_Extra_Gallwwwanim
gid_File_Extra_Tplwizletter_ko
gid_File_Lib_Mingw_Stdcpp
gid_File_Tmp_Inf_Oldreg
gid_File_Lib_Sndfile
gid_File_Lib_AVMediaGst
gid_File_Res_Tab
gid_File_Lib_Sogpstarter
gid_File_Tmp_Userinstall_Draw_Inf
gid_File_Xsl_Export_Xhtml_Master_Document
gid_File_Lib_GdiPlusCanvas
gid_File_Xsl_Export_Xhtml_Master_Refs_Workaround
gid_File_Lib_Zip
gid_File_Kspprof_Ini
gid_File_Extra_Urltasks_Impress
gid_File_Lib_DirectX9Canvas
gid_File_Bin_Gengal
gid_File_Tabaction
gid_File_Bin_Cde_Smemo
gid_File_Dl_Policy_Cli_Ure_Assembly
gid_File_Lib_Mingw_Stdcpp_Ure
gid_File_Lib_Vclplug_Kde4
gid_File_Lib_I18n
gid_File_Lib_Qslnkmsi
gid_File_Lib_Ole
gid_File_Py_Scriptprovider
gid_File_Lib_Mingw_GccS_Ure
gid_File_Jar_Bsh
gid_File_Res_Stt
gid_File_Lib_Lprxw
gid_File_Tmp_Userinstall_Pocketpcexcel_Inf
gid_Brand_File_Lib_Dbghelp
gid_File_Lib_Reg4allmsdoc
gid_File_Sp_Jlsf_Mcd
gid_Brand_File_Res_Oirm
gid_File_Bin_Cde_Slabel
gid_File_Fnt_LiberationSans_Italic
gid_File_Bmp_Installation
gid_File_Lib_Kab_Drv_1
gid_File_Lib_Tfu
gid_File_Extra_Urltasks_Calc
gid_File_Extra_Urlnew_Math
gid_File_Lib_Gconfebe
gid_File_Lib_Pl
gid_File_Lib_Policy_Cli_Oootypes_Config
gid_File_Extra_Tplwizmemo_Lang
gid_File_Lib_Policy_Cli_Cppuhelper_Assembly
gid_File_Bin_Cde_Svcard
gid_File_Lib_Macbe
gid_File_Res_Productregistration
gid_File_Jar_Email
gid_File_Dl_Policy_Cli_Uretypes_Config
gid_File_ImagesTango_Zip
gid_File_Lib_Fop
gid_File_Server_Bonobo_Presentationstarter
gid_File_Extra_Tplwizletter_it
gid_File_Xsl_Export_Common_Styles_Style_Mapping_html32
gid_File_Lib_Hunspell
gid_File_Dl_Policy_Cli_Basetypes_Config
gid_File_Share_Config_Sofficecfg_Draw_Menubar_Xml
gid_File_Share_Config_Sofficecfg_Dburelation_Menubar_Xml
gid_File_Lib_Dtrans
gid_File_Dl_Policy_Cli_Cppuhelper_Assembly
gid_Brand_File_Bin_Crashreport_Script
gid_File_Dl_Uwinapi
gid_File_Extra_Autotextuser_Lang
gid_File_Lib_LibXMLSec_xmlsecnss
gid_File_Lib_Ado
gid_File_Lib_Mingw_GccS
gid_File_Lib_LibXMLSec_xmlseccore
gid_File_Lib_Neon
gid_File_Share_Registry_Forcedefault_Xcd
gid_File_Dl_Cli_Ure_Assembly
gid_File_Shellnew_Ods_Soffice
gid_File_Res_Tk
gid_File_Exe_Sweb
gid_File_Share_Config_Sofficecfg_Dbuapp_Menubar_Xml
gid_File_Fnt_LiberationSerif_Regular
gid_Brand_File_Bin_Unopkgcom
gid_File_Extra_Urlstart_Draw
gid_File_Extra_Urlstart_Calc
gid_File_Fnt_LiberationMono_Regular
gid_File_Lib_relnotes
gid_File_Share_Config_Sofficecfg_Dbutable_Menubar_Xml
gid_File_Sp_Adsf_Mcd
gid_File_Res_Gallery
gid_File_Dl_Cli_Uretypes_Assembly
gid_File_Dl_Policy_Cli_Cppuhelper_Config
gid_File_Lib_Bat
gid_File_Sp_Subm_Mcd
gid_File_Fnt_LiberationSans_Regular
gid_File_Shellnew_Odp_Soffice
gid_File_Exe_Userinst
gid_Brand_File_Lib_Oirm2
gid_File_Profile_Gengal
gid_File_Fnt_LiberationSerif_BoldItalic
gid_File_Dl_Cli_Uno
gid_File_Sp_Klsf_Mcd
gid_Brand_File_Lib_Npsoplugin
gid_File_Lib_Agg
gid_File_Lib_Onlinecheck
gid_File_Fnt_LibSansNarrow_Bold
gid_File_Lib_Macab_Drv_1
gid_File_Extra_Urlnew_Draw
gid_File_Extra_Urldesktop_Calc
gid_File_Dl_Policy_Cli_Ure_Config
gid_File_Lib_Sysdtrans
gid_File_Fnt_LiberationSans_BoldItalic
gid_File_Lib_Kab_1
gid_File_Exe_Adabas
gid_File_Lib_LibXMLSec_xmlsecmscrypto
gid_File_Lib_Lks
gid_File_Fn

Re: 4.1.8-RC3

[Don Lewis]

On 30 Oct, Pedro Lino wrote:
> Just recompiled AOO 4.1.8 on another Ubuntu 18.04.5 x64 without issues.
> 
> Installing 4.1.8 over 4.1.7 end with error reported 2 years ago
> 
> https://bz.apache.org/ooo/show_bug.cgi?id=127774

I just updated that ticket with some new information.  It is possible to
debug this by rebuilding just the scp2 module and looking at
scp2/unxlngx6.pro/bin/osl/setup_osl.ins

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.1.8-RC3

[Don Lewis]

On 29 Oct, Jim Jagielski wrote:
> I think we are ready for 4.1.8-RC3. I'll start Linux and macOS builds.

Building on CentOS 5 and running both on CentOS 5 and Ubuntu 16 seem to
work.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [openoffice] branch AOO418 updated: Fix redland build issues when using CentOS5 as build and later platforms as user. Squash General Error.

[Don Lewis]

trunk and AOO42X should also get this fix.

On 29 Oct, j...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> jim pushed a commit to branch AOO418
> in repository https://gitbox.apache.org/repos/asf/openoffice.git
> 
> 
> The following commit(s) were added to refs/heads/AOO418 by this push:
>  new 18848f5  Fix redland build issues when using CentOS5 as build and 
> later platforms as user. Squash General Error.
> 18848f5 is described below
> 
> commit 18848f57b67aa11f5b2c6c4b82e9d93676d1b57a
> Author: Jim Jagielski 
> AuthorDate: Thu Oct 29 07:39:50 2020 -0400
> 
> Fix redland build issues when using CentOS5 as build and later platforms 
> as user. Squash General Error.
> ---
>  main/redland/raptor/makefile.mk | 2 +-
>  main/redland/rasqal/makefile.mk | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/main/redland/raptor/makefile.mk b/main/redland/raptor/makefile.mk
> index 51b7876..0c8b6a4 100644
> --- a/main/redland/raptor/makefile.mk
> +++ b/main/redland/raptor/makefile.mk
> @@ -128,7 +128,7 @@ XSLTLIB!:=$(XSLTLIB) # expand dmake variables for 
> xslt-config
>  CONFIGURE_DIR=
>  CONFIGURE_ACTION=.$/configure
>  # do not enable grddl parser (#i93768#)
> -CONFIGURE_FLAGS=--disable-static --disable-gtk-doc --enable-parsers="rdfxml 
> ntriples turtle trig guess rss-tag-soup" --with-www=xml 
> --prefix=$(PDW)/$(OUT) --includedir=$(PWD)/$(INCCOM) --libdir=$(PWD)/$(LB)
> +CONFIGURE_FLAGS=--with-threads --with-curl-config=no --with-icu-config=no 
> --disable-static --disable-gtk-doc --enable-parsers="rdfxml ntriples turtle 
> trig guess rss-tag-soup" --without-bdb --without-sqlite --without-mysql 
> --without-postgresql --without-threestore --with-regex-library=posix 
> --with-decimal=none --with-www=xml --prefix=$(PDW)/$(OUT) 
> --includedir=$(PWD)/$(INCCOM) --libdir=$(PWD)/$(LB)
>  .IF "$(SYSTEM_LIBXML)" == "NO"
>  
> CONFIGURE_FLAGS+=--with-xml2-config=${SOLARVERSION}/${INPATH}/bin/xml2-config 
> \
>   --with-xslt-config=${SOLARVERSION}/${INPATH}/bin/xslt-config
> diff --git a/main/redland/rasqal/makefile.mk b/main/redland/rasqal/makefile.mk
> index 72a4368..b95d8ca 100644
> --- a/main/redland/rasqal/makefile.mk
> +++ b/main/redland/rasqal/makefile.mk
> @@ -125,7 +125,7 @@ XSLTLIB!:=$(XSLTLIB) # expand dmake variables for 
> xslt-config
>  
>  CONFIGURE_DIR=
>  CONFIGURE_ACTION=.$/configure PATH="..$/..$/..$/bin:$$PATH" 
> RASQAL_CFLAGS=-I${PWD}$/..$/${INPATH}/inc 
> RASQAL_LIBS="-L${PWD}/..$/${INPATH}/lib -lrasqual" 
> RAPTOR2_CFLAGS=-I${PWD}$/..$/${INPATH}/inc 
> RAPTOR2_LIBS="-L${PWD}/..$/${INPATH}/lib -lraptor2" 
> PKG_CONFIG_PATH="../raptor2-2.0.15:../rasqal-0.9.33"
> -CONFIGURE_FLAGS=--disable-static --disable-gtk-doc 
> --with-regex-library=posix --with-decimal=none
> +CONFIGURE_FLAGS=--disable-static --disable-gtk-doc 
> --with-regex-library=posix --with-decimal=none --with-libgcrypt-config=no
>  .IF "$(SYSTEM_LIBXML)" == "NO"
>  CONFIGURE_FLAGS+=--with-xml2-config=${SOLARVERSION}/${INPATH}/bin/xml2-config
>  .ENDIF
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

[Don Lewis]

On 28 Oct, Don Lewis wrote:
> On 28 Oct, Don Lewis wrote:
>> On 27 Oct, Don Lewis wrote:
>>> On 27 Oct, Jim Jagielski wrote:
>>>> Maybe... but it DID WORK before. That is, before the mega patch,
>>>> configure did the "right thing". So if something is causing configure
>>>> to make a different decision, it is due to the interaction w/ the new
>>>> stuff that the RDF stuff does. The problem is with the patch or how it
>>>> is working...
>>> 
>>> I'm thinking of any configure scripts used by raptor / rasqal / redland,
>>> which would have changed by the upgrade.
>> 
>> I took a look at the configure outputs for those three.  I did see some
>> significant differences for redland.  In particular, on CentOS 5,
>> redland was picking up a system version of curl.  I think I installed a
>> newer version of curl, liked with a modern verson of openssl so a newer
>> version of git would work with github.  Thinking that librdf might have
>> been linked to the system libcurl, I uninstalled curl on the CentOS5 box
>> and did a another rebuild.  I still saw breakage when I installed the
>> packages on Ubuntu 16.
>> 
>> Digging in some more, I ran ldd on the librdf.so that we build and
>> discovered that libgcrypt was not being found.  On CentOS 5, libgcrypt
>> is version 11.5.2 and on Ubuntu 16 it is 20.0.5.  That's a problem.  I
>> wonder if redland actually needs libgcrypt for our purposes.
> 
> libraptor2 wants to link to the system icu libraries.  I haven't quite
> figured out why raptor2 wants to use icu and the older raptor library
> does not seem to need it.

>From http://librdf.org/raptor/RELEASE.html, please read the last
paragraph:

Raptor2 2.0.7 changes

CVE-2012-0037 fixed

Issues Fixed:

448: Turtle parser does not return error status from 
turtle_parse_chunk()
469: Allow rapper to bypass server SSL certs checks in libcurl

Removed Expat support since expat has not had a release in years and
libxml2 works well. This allows some code simplification. Updated
configure so that if Raptor is configured with no parser that requires
an XML parser, libxml2 will not be required.

Removed internal Unicode NFC checking code used for checking RDF/XML
literals conformance which was expensive to check and a large of
compiled-in static dataset that was rather out of date. Replaced with
optional compiled use of ICU. If ICU is not explicitly configured, no
literal checking is done.


I think I've got a patch that eliminates the ICU dependency.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

[Don Lewis]

On 28 Oct, Don Lewis wrote:
> On 27 Oct, Don Lewis wrote:
>> On 27 Oct, Jim Jagielski wrote:
>>> Maybe... but it DID WORK before. That is, before the mega patch,
>>> configure did the "right thing". So if something is causing configure
>>> to make a different decision, it is due to the interaction w/ the new
>>> stuff that the RDF stuff does. The problem is with the patch or how it
>>> is working...
>> 
>> I'm thinking of any configure scripts used by raptor / rasqal / redland,
>> which would have changed by the upgrade.
> 
> I took a look at the configure outputs for those three.  I did see some
> significant differences for redland.  In particular, on CentOS 5,
> redland was picking up a system version of curl.  I think I installed a
> newer version of curl, liked with a modern verson of openssl so a newer
> version of git would work with github.  Thinking that librdf might have
> been linked to the system libcurl, I uninstalled curl on the CentOS5 box
> and did a another rebuild.  I still saw breakage when I installed the
> packages on Ubuntu 16.
> 
> Digging in some more, I ran ldd on the librdf.so that we build and
> discovered that libgcrypt was not being found.  On CentOS 5, libgcrypt
> is version 11.5.2 and on Ubuntu 16 it is 20.0.5.  That's a problem.  I
> wonder if redland actually needs libgcrypt for our purposes.

libraptor2 wants to link to the system icu libraries.  I haven't quite
figured out why raptor2 wants to use icu and the older raptor library
does not seem to need it.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

[Don Lewis]

On 27 Oct, Don Lewis wrote:
> On 27 Oct, Jim Jagielski wrote:
>> Maybe... but it DID WORK before. That is, before the mega patch,
>> configure did the "right thing". So if something is causing configure
>> to make a different decision, it is due to the interaction w/ the new
>> stuff that the RDF stuff does. The problem is with the patch or how it
>> is working...
> 
> I'm thinking of any configure scripts used by raptor / rasqal / redland,
> which would have changed by the upgrade.

I took a look at the configure outputs for those three.  I did see some
significant differences for redland.  In particular, on CentOS 5,
redland was picking up a system version of curl.  I think I installed a
newer version of curl, liked with a modern verson of openssl so a newer
version of git would work with github.  Thinking that librdf might have
been linked to the system libcurl, I uninstalled curl on the CentOS5 box
and did a another rebuild.  I still saw breakage when I installed the
packages on Ubuntu 16.

Digging in some more, I ran ldd on the librdf.so that we build and
discovered that libgcrypt was not being found.  On CentOS 5, libgcrypt
is version 11.5.2 and on Ubuntu 16 it is 20.0.5.  That's a problem.  I
wonder if redland actually needs libgcrypt for our purposes.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: building from a source tarball

[Don Lewis]

On 28 Oct, Jim Jagielski wrote:
> In particular, this is when building from the "official" SRC_RELEASE
> tarball we provide. Is the inc/reporevision.lst file not included?

It is in one of the RCs that I looked at.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: building from a source tarball

[Don Lewis]

On 28 Oct, Matthias Seidel wrote:
> Hi Don,
> 
> This should be working since last year?
> 
> https://github.com/apache/openoffice/commit/0c6d6194a959cb1b87417e9077dc1d8ece630b11

Item #2 here:
  
https://lists.apache.org/thread.html/r228db9ac55fc89c7286943f31cfd862d944c45264cdd6f662dc2a8f9%40%3Cdev.openoffice.apache.org%3E

> Regards,
> 
>    Matthias
> 
> Am 28.10.20 um 18:33 schrieb Don Lewis:
>> Something that we are still missing for AOO418 is a  fix for getting the
>> revision info when building from a source tarball instead of a git
>> checkout.  Someone mentioned this a couple weeks ago.
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

building from a source tarball

[Don Lewis]

Something that we are still missing for AOO418 is a  fix for getting the
revision info when building from a source tarball instead of a git
checkout.  Someone mentioned this a couple weeks ago.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

[Don Lewis]

On 27 Oct, Jim Jagielski wrote:
> Maybe... but it DID WORK before. That is, before the mega patch,
> configure did the "right thing". So if something is causing configure
> to make a different decision, it is due to the interaction w/ the new
> stuff that the RDF stuff does. The problem is with the patch or how it
> is working...

I'm thinking of any configure scripts used by raptor / rasqal / redland,
which would have changed by the upgrade.

> In any case, iirc we did compare the config.log files between 4.1.7
> and 4.1.8-RC2 and there was no pertinent difference between the 2...
> 
>> On Oct 27, 2020, at 5:24 PM, Don Lewis  wrote:
>> 
>> On 27 Oct, Jim Jagielski wrote:
>>> For completeness, and especially for those not following the thread,
>>> what we have conclusively shown is that it is NOT an issue w/ the
>>> build server, which is the same we've been using for several 4.1.x
>>> releases, nor with the configure and build parameters (also
>>> unchanged from previous). It is this mega patch which combines
>>> several upgrades in one large patch.
>>> 
>>> My thought is that w/ the change with the RDF libs, the patch either
>>> pulls in the wrong library (maybe the system library) for something,
>>> which causes issues w/ newer distros, or else it doesn't pull in a
>>> library and the one used by newer distros causes the problem.
>> 
>> Or maybe a configure script makes a different decision about the
>> system libraries on CentOS 5 (vs when building on something newer)
>> that causes the code not to work properly on newer distros.
>> 
>>>> On Oct 27, 2020, at 5:09 PM, Jim Jagielski  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Oct 27, 2020, at 2:34 PM, Don Lewis  wrote:
>>>>> 
>>>>> On 27 Oct, Jim Jagielski wrote:
>>>>>> Thanks all... I am now building the final 'git bisect' test,
>>>>>> based on
>>>>>> 
>>>>>>  
>>>>>> https://github.com/apache/openoffice/commit/f7070ae3689d0d34bf9dab3d31f56744d0df4784
>>>>>> 
>>>>>> assuming that this is good, it seems like 99% likely that the
>>>>>> problem arose with
>>>>>> 
>>>>>>  
>>>>>> https://github.com/apache/openoffice/commit/e9fab906a0063dca04a52bfc5270c9d70ccbbb27
>>>>>> 
>>>>>> the raptor / rasqal / redland mega patch. Which of those 3 is
>>>>>> unknown, but a quick look over seems to indicate that the raptor
>>>>>> upgrade was the most significant of the 3, but the redland patch
>>>>>> also seems to have some weird things (like no longer linking
>>>>>> openssl or libltdl) so who knows :/
>>>>> 
>>>>> Questions (which may be related):
>>>>> 
>>>>> Why does this only affect AOO418 and not AOO42X and trunk?
>>>>> 
>>>>> Why does this only seem to affect builds done on CentOS 5 and run
>>>>> on a newer distro and not when run on CentOS 5 and not when
>>>>> compiled on a newer distro?
>>>> 
>>>> If I knew those answers we wouldn't be wondering what is going on
>>>> and I wouldn't have had to create >15 test builds :-)
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>> <mailto:dev-unsubscr...@openoffice.apache.org> For additional
>>>> commands, e-mail: dev-h...@openoffice.apache.org
>>>> <mailto:dev-h...@openoffice.apache.org>
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> <mailto:dev-unsubscr...@openoffice.apache.org> For additional
>> commands, e-mail: dev-h...@openoffice.apache.org
>> <mailto:dev-h...@openoffice.apache.org>


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

[Don Lewis]

On 27 Oct, Jim Jagielski wrote:
> For completeness, and especially for those not following the thread,
> what we have conclusively shown is that it is NOT an issue w/ the
> build server, which is the same we've been using for several 4.1.x
> releases, nor with the configure and build parameters (also unchanged
> from previous). It is this mega patch which combines several upgrades
> in one large patch.
> 
> My thought is that w/ the change with the RDF libs, the patch either
> pulls in the wrong library (maybe the system library) for something,
> which causes issues w/ newer distros, or else it doesn't pull in a
> library and the one used by newer distros causes the problem.

Or maybe a configure script makes a different decision about the system
libraries on CentOS 5 (vs when building on something newer) that causes
the code not to work properly on newer distros.

>> On Oct 27, 2020, at 5:09 PM, Jim Jagielski  wrote:
>> 
>> 
>> 
>>> On Oct 27, 2020, at 2:34 PM, Don Lewis  wrote:
>>> 
>>> On 27 Oct, Jim Jagielski wrote:
>>>> Thanks all... I am now building the final 'git bisect' test, based
>>>> on
>>>> 
>>>>   
>>>> https://github.com/apache/openoffice/commit/f7070ae3689d0d34bf9dab3d31f56744d0df4784
>>>> 
>>>> assuming that this is good, it seems like 99% likely that the
>>>> problem arose with
>>>> 
>>>>   
>>>> https://github.com/apache/openoffice/commit/e9fab906a0063dca04a52bfc5270c9d70ccbbb27
>>>> 
>>>> the raptor / rasqal / redland mega patch. Which of those 3 is
>>>> unknown, but a quick look over seems to indicate that the raptor
>>>> upgrade was the most significant of the 3, but the redland patch
>>>> also seems to have some weird things (like no longer linking
>>>> openssl or libltdl) so who knows :/
>>> 
>>> Questions (which may be related):
>>> 
>>> Why does this only affect AOO418 and not AOO42X and trunk?
>>> 
>>> Why does this only seem to affect builds done on CentOS 5 and run on
>>> a newer distro and not when run on CentOS 5 and not when compiled on
>>> a newer distro?
>> 
>> If I knew those answers we wouldn't be wondering what is going on and
>> I wouldn't have had to create >15 test builds :-)
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> <mailto:dev-unsubscr...@openoffice.apache.org> For additional
>> commands, e-mail: dev-h...@openoffice.apache.org
>> <mailto:dev-h...@openoffice.apache.org>


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: test12 (Was: Re: test11 (Was: Re: test2 is ready to run))

[Don Lewis]

On 27 Oct, Jim Jagielski wrote:
> Thanks all... I am now building the final 'git bisect' test, based on
> 
> 
> https://github.com/apache/openoffice/commit/f7070ae3689d0d34bf9dab3d31f56744d0df4784
> 
> assuming that this is good, it seems like 99% likely that the problem arose 
> with
> 
> 
> https://github.com/apache/openoffice/commit/e9fab906a0063dca04a52bfc5270c9d70ccbbb27
> 
> the raptor / rasqal / redland mega patch. Which of those 3 is unknown, but a 
> quick look over seems to indicate that the raptor upgrade was the most 
> significant of the 3, but the redland patch also seems to have some weird 
> things (like no longer linking openssl or libltdl) so who knows :/

Questions (which may be related):

Why does this only affect AOO418 and not AOO42X and trunk?

Why does this only seem to affect builds done on CentOS 5 and run on a
newer distro and not when run on CentOS 5 and not when compiled on a
newer distro?


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: openssl upgrade for 4.1.8

[Don Lewis]

On 22 Oct, Jim Jagielski wrote:
> Regarding this commit:
> 
>
> https://github.com/apache/openoffice/commit/8d4c92f789718b2f73ea62d487811a0c9d476739
> 
> why the change 
> 
>   - CONFIGURE_ACTION=Configure linux-generic64
>   + CONFIGURE_ACTION=Configure linux-x86_64 no-dso no-shared $(NO_ASM)
> 
> that seems a major change to how we build openssl for AOO.

That's what we do in trunk/AOO42X.  The ASM stuff my use new
instructions that aren't supported on older hardware.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418-RC2: General Error on opening files on Ubuntu

[Don Lewis]

On 21 Oct, Don Lewis wrote:
> On 21 Oct, Don Lewis wrote:
>> On 21 Oct, Jim Jagielski wrote:
>>> 
>>> 
>>>> On Oct 21, 2020, at 4:21 PM, Andrea Pescetti 
>>>> wrote:
>>>> 
>>>> It looks like we are getting closer I mean, we have a commit that
>>>> is only relevant to CentOS 5 and we know that Jim's builds are done
>>>> on CentOS 5 and have the bug, while the others (mine on CentOS 7;
>>>> Pedro's on Ubuntu 18) do not have it.
>>>> 
>>>> Possibly some build error that goes unnoticed due to a "dirty" build?
>>>> Otherwise I can't explain why Don's CentOS 5 tests passed...
>>>> 
>>> 
>>> I don't think anyone else tested Don's CentOS5 built builds... just
>>> himself. I think.
>> 
>> I only tested my CentOS 5 build on CentOS 5.  I think the problem only
>> occurs when running a CentOS 5 build on something newer (Ubuntu only?).
>> This sort of smells like a system library incompatability of some sort.
>> Things work when the build is done using the system headers that match
>> the destination environment, but the problem crops up if the build is
>> done with the CentOS 5 headers but the runtime libraries are from a
>> newer distro. The mystery is what changed between 4.1.7 and now to
>> trigger the problem.
> 
> I only have a 32-bit CentOS 5 VM.  My bare-metal Debian stretch machine
> is 64 bits, so I wasn't able to test the CentOS 5 build on Debian.
> 
> If I take the output from the 32-bit CentOS 5 build on a 32-bit Ubuntu
> 16 VM, I can reproduce the problem.  I'm currently building the same git
> revision on Ubuntu 16.  I suspect that I won't see the problem with that
> combo.

If I build the same git revision of AOO418 on Ubuntu 16, then install
and run it there, I do *not* see the General Error problem.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418-RC2: General Error on opening files on Ubuntu

[Don Lewis]

On 21 Oct, Don Lewis wrote:
> On 21 Oct, Jim Jagielski wrote:
>> 
>> 
>>> On Oct 21, 2020, at 4:21 PM, Andrea Pescetti 
>>> wrote:
>>> 
>>> It looks like we are getting closer I mean, we have a commit that
>>> is only relevant to CentOS 5 and we know that Jim's builds are done
>>> on CentOS 5 and have the bug, while the others (mine on CentOS 7;
>>> Pedro's on Ubuntu 18) do not have it.
>>> 
>>> Possibly some build error that goes unnoticed due to a "dirty" build?
>>> Otherwise I can't explain why Don's CentOS 5 tests passed...
>>> 
>> 
>> I don't think anyone else tested Don's CentOS5 built builds... just
>> himself. I think.
> 
> I only tested my CentOS 5 build on CentOS 5.  I think the problem only
> occurs when running a CentOS 5 build on something newer (Ubuntu only?).
> This sort of smells like a system library incompatability of some sort.
> Things work when the build is done using the system headers that match
> the destination environment, but the problem crops up if the build is
> done with the CentOS 5 headers but the runtime libraries are from a
> newer distro. The mystery is what changed between 4.1.7 and now to
> trigger the problem.

I only have a 32-bit CentOS 5 VM.  My bare-metal Debian stretch machine
is 64 bits, so I wasn't able to test the CentOS 5 build on Debian.

If I take the output from the 32-bit CentOS 5 build on a 32-bit Ubuntu
16 VM, I can reproduce the problem.  I'm currently building the same git
revision on Ubuntu 16.  I suspect that I won't see the problem with that
combo.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418-RC2: General Error on opening files on Ubuntu

[Don Lewis]

On 22 Oct, Matthias Seidel wrote:
> Hi Jim,
> 
> Am 21.10.20 um 20:48 schrieb Jim Jagielski:
>> In the meantime, please review main/writerfilter/source/doctok/resources.xsl 
>> on trunk and AOO42X
> 
> Windows Buildbot (AOO42X) just stopped with this error:
> 
> 1 module(s): writerfilter need(s) to be rebuilt Reason(s): ERROR: error
> 65280 occurred while making
> /cygdrive/e/slave14/openoffice-win7-41x/build/main/writerfilter/prj When
> you have fixed the errors in that module you can resume the build by
> running: build --from writerfilter

Sounds like
  test="string-length($shift)!=0"
doesn't work, which is odd ...

>>
>>> On Oct 21, 2020, at 2:41 PM, Don Lewis  wrote:
>>>
>>> On 21 Oct, Jim Jagielski wrote:
>>>> OK... so $shift is a number then, or should be? But sometimes $shift
>>>> is simply blank. And we want a black $shift to be evaluated as 0. So
>>>> if all that is correct, could we use number($shift)>0 ?
>>> The input file that generates the header doesn't specifiy $shift in
>>> all cases, so I assume that $shift is treated as an empty string.
>>>
>>> Something I thought would work was test="$shift" since either an empty
>>> string or a zero in a boolean context should evaluate to false, but for
>>> some reason it did not work.
>>>
>>> I didn't stumble across number() in my reading.  I don't know what
>>> number() would do in this situation.
>>>
>>>> I'm thinking this isn't the problem though with the failures :/
>>> Yeah, I think it's probably something else that went in at the same time,
>>> and I think also that build OS vs. deployment OS is part of the mix.
>>>
>>>>> On Oct 21, 2020, at 2:15 PM, Don Lewis  wrote:
>>>>>
>>>>> On 21 Oct, Jim Jagielski wrote:
>>>>>> Should that fix be just:
>>>>>>
>>>>>>   
>>>>> That would work, but it would produce a different output.  It would
>>>>> always put ">> $shift" in the output whenever $shift is nonblank. 
>>>>> The change that I committed only puts ">> $shift" in the output if
>>>>> $shift is nonblank and greater than zero.  This is what the original
>>>>> version does with older versions of libxslt, or when building on
>>>>> anything newer than CentOS 5.
>>>>>
>>>>>>> On Oct 21, 2020, at 11:37 AM, Jim Jagielski  wrote:
>>>>>>>
>>>>>>> I don't have it, but that was around the end of Aug right? So right
>>>>>>> around the time when a bunch of stuff was included like updates to
>>>>>>> nss, libxslt, libxml2...
>>>>>>>
>>>>>>> I'm trying to get my head around the logic of
>>>>>>>
>>>>>>>  
>>>>>>> https://github.com/apache/openoffice/commit/9510f3847723b65ae47efff8796e6f14f586ce09
>>>>>>>
>>>>>>>> On Oct 21, 2020, at 10:58 AM, Matthias Seidel
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> Hi Jim,
>>>>>>>>
>>>>>>>> Am 21.10.20 um 16:54 schrieb Jim Jagielski:
>>>>>>>>> Let me double check.. I am rebuilding AOO417. Lets see if that
>>>>>>>>> works.
>>>>>>>>>
>>>>>>>>> PS: The one change that DID happen is that I upgraded Vmware
>>>>>>>>> Fusion, which I use to run the CentOS5 VMs. That should NOT make
>>>>>>>>> any difference. But we will see.
>>>>>>>>>
>>>>>>>>> I'll posted when my 4.1.7 test builds are ready. TIA!
>>>>>>>> To be clear, the last version that worked for me was 4.1.8.
>>>>>>>> But it was before we built Release Candidates.
>>>>>>>>
>>>>>>>> Unfortunately, I didn't keep it, but maybe you can upload it again?
>>>>>>>>
>>>>>>>>> -
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>>>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>>>>>>>
>>>>>>>
>>>>>>> -
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>>> <mailto:dev-unsubscr...@openoffice.apache.org> For additional
>>>>> commands, e-mail: dev-h...@openoffice.apache.org
>>>>> <mailto:dev-h...@openoffice.apache.org>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
>>> <mailto:dev-unsubscr...@openoffice.apache.org>
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>>> <mailto:dev-h...@openoffice.apache.org>


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418-RC2: General Error on opening files on Ubuntu

[Don Lewis]

On 21 Oct, Jim Jagielski wrote:
> 
> 
>> On Oct 21, 2020, at 4:21 PM, Andrea Pescetti 
>> wrote:
>> 
>> It looks like we are getting closer I mean, we have a commit that
>> is only relevant to CentOS 5 and we know that Jim's builds are done
>> on CentOS 5 and have the bug, while the others (mine on CentOS 7;
>> Pedro's on Ubuntu 18) do not have it.
>> 
>> Possibly some build error that goes unnoticed due to a "dirty" build?
>> Otherwise I can't explain why Don's CentOS 5 tests passed...
>> 
> 
> I don't think anyone else tested Don's CentOS5 built builds... just
> himself. I think.

I only tested my CentOS 5 build on CentOS 5.  I think the problem only
occurs when running a CentOS 5 build on something newer (Ubuntu only?).
This sort of smells like a system library incompatability of some sort.
Things work when the build is done using the system headers that match
the destination environment, but the problem crops up if the build is
done with the CentOS 5 headers but the runtime libraries are from a
newer distro. The mystery is what changed between 4.1.7 and now to
trigger the problem.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418-RC2: General Error on opening files on Ubuntu

[Don Lewis]

On 21 Oct, Jim Jagielski wrote:
> never mind this... it's not a matter of building. I can build fine. It
> just crashes on Ubuntu. no idea why.

Are you building on the same version of Ubuntu?


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418-RC2: General Error on opening files on Ubuntu

[Don Lewis]

On 21 Oct, Jim Jagielski wrote:
> OK... so $shift is a number then, or should be? But sometimes $shift
> is simply blank. And we want a black $shift to be evaluated as 0. So
> if all that is correct, could we use number($shift)>0 ?

The input file that generates the header doesn't specifiy $shift in
all cases, so I assume that $shift is treated as an empty string.

Something I thought would work was test="$shift" since either an empty
string or a zero in a boolean context should evaluate to false, but for
some reason it did not work.

I didn't stumble across number() in my reading.  I don't know what
number() would do in this situation.
  
> I'm thinking this isn't the problem though with the failures :/

Yeah, I think it's probably something else that went in at the same time,
and I think also that build OS vs. deployment OS is part of the mix.
 
>> On Oct 21, 2020, at 2:15 PM, Don Lewis  wrote:
>> 
>> On 21 Oct, Jim Jagielski wrote:
>>> Should that fix be just:
>>> 
>>>
>> 
>> That would work, but it would produce a different output.  It would
>> always put ">> $shift" in the output whenever $shift is nonblank. 
>> The change that I committed only puts ">> $shift" in the output if
>> $shift is nonblank and greater than zero.  This is what the original
>> version does with older versions of libxslt, or when building on
>> anything newer than CentOS 5.
>> 
>>> 
>>>> On Oct 21, 2020, at 11:37 AM, Jim Jagielski  wrote:
>>>> 
>>>> I don't have it, but that was around the end of Aug right? So right
>>>> around the time when a bunch of stuff was included like updates to
>>>> nss, libxslt, libxml2...
>>>> 
>>>> I'm trying to get my head around the logic of
>>>> 
>>>>   
>>>> https://github.com/apache/openoffice/commit/9510f3847723b65ae47efff8796e6f14f586ce09
>>>> 
>>>>> On Oct 21, 2020, at 10:58 AM, Matthias Seidel
>>>>>  wrote:
>>>>> 
>>>>> Hi Jim,
>>>>> 
>>>>> Am 21.10.20 um 16:54 schrieb Jim Jagielski:
>>>>>> Let me double check.. I am rebuilding AOO417. Lets see if that
>>>>>> works.
>>>>>> 
>>>>>> PS: The one change that DID happen is that I upgraded Vmware
>>>>>> Fusion, which I use to run the CentOS5 VMs. That should NOT make
>>>>>> any difference. But we will see.
>>>>>> 
>>>>>> I'll posted when my 4.1.7 test builds are ready. TIA!
>>>>> 
>>>>> To be clear, the last version that worked for me was 4.1.8.
>>>>> But it was before we built Release Candidates.
>>>>> 
>>>>> Unfortunately, I didn't keep it, but maybe you can upload it again?
>>>>> 
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>> 
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> <mailto:dev-unsubscr...@openoffice.apache.org> For additional
>> commands, e-mail: dev-h...@openoffice.apache.org
>> <mailto:dev-h...@openoffice.apache.org>


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418-RC2: General Error on opening files on Ubuntu

[Don Lewis]

On 21 Oct, Jim Jagielski wrote:
> so are YOU able to build HEAD of AOO418 on CentOS5 ??

I haven't tried to build today's HEAD, but I've built and tested all of
my AOO418 commits on CentOS 5 before I made the commits.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418-RC2: General Error on opening files on Ubuntu

[Don Lewis]

On 21 Oct, Matthias Seidel wrote:
> Am 21.10.20 um 17:43 schrieb Jim Jagielski:
>> Should that fix be just:
>>
>> 
> 
> https://github.com/apache/openoffice/commit/9510f3847723b65ae47efff8796e6f14f586ce09
> 
> Really looks like a candidate...

I doubt it. Unless you are building on CentOS 5,
writerfilter/.../inc/doctok/resources.hxx is identical with or without this
commit.  On CentOS 5, resources.hxx differs, and causes a compile error
because it contains the correct C expression "something >> ".

I didn't commit this change to trunk or AOO42X because the problem only
shows up when building on CentOS 5.

Also, I believe that we've seen this problem previously on trunk and/or
AOO42X that does not have this commit but the problem has mysteriously
gone away, and it seems to be related to the combination of what OS the
build was done on and what OS the resulting binaries are run on.

I've done testing on CentOS 5, CentOS 7, Debian stretch and a bit of
testing on Ubuntu and have never run into this problem, *but* I've
always run the binaries on the same OS where they were compiled.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418-RC2: General Error on opening files on Ubuntu

[Don Lewis]

On 21 Oct, Jim Jagielski wrote:
> Should that fix be just:
> 
> 

That would work, but it would produce a different output.  It would
always put ">> $shift" in the output whenever $shift is nonblank.  The
change that I committed only puts ">> $shift" in the output if $shift is
nonblank and greater than zero.  This is what the original version does
with older versions of libxslt, or when building on anything newer than
CentOS 5.

> 
>> On Oct 21, 2020, at 11:37 AM, Jim Jagielski  wrote:
>> 
>> I don't have it, but that was around the end of Aug right? So right around 
>> the time when a bunch of stuff was included like updates to nss, libxslt, 
>> libxml2...
>> 
>> I'm trying to get my head around the logic of
>> 
>>
>> https://github.com/apache/openoffice/commit/9510f3847723b65ae47efff8796e6f14f586ce09
>> 
>>> On Oct 21, 2020, at 10:58 AM, Matthias Seidel  
>>> wrote:
>>> 
>>> Hi Jim,
>>> 
>>> Am 21.10.20 um 16:54 schrieb Jim Jagielski:
 Let me double check.. I am rebuilding AOO417. Lets see if that works.
 
 PS: The one change that DID happen is that I upgraded Vmware Fusion, which 
 I use to run the CentOS5 VMs. That should NOT make any difference. But we 
 will see.
 
 I'll posted when my 4.1.7 test builds are ready. TIA!
>>> 
>>> To be clear, the last version that worked for me was 4.1.8.
>>> But it was before we built Release Candidates.
>>> 
>>> Unfortunately, I didn't keep it, but maybe you can upload it again?
>>> 
 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org
 
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418-RC2: General Error on opening files on Ubuntu

[Don Lewis]

On 21 Oct, Jim Jagielski wrote:
> I don't have it, but that was around the end of Aug right? So right around 
> the time when a bunch of stuff was included like updates to nss, libxslt, 
> libxml2...
> 
> I'm trying to get my head around the logic of
> 
> 
> https://github.com/apache/openoffice/commit/9510f3847723b65ae47efff8796e6f14f586ce09

If $shift is blank then "$shift>0" becomes ">0", which is a malformed
expression.  For some reason, it still works correctly in most cases.
The case where it does not is with the latest libxslt when built on
CentOS 5.  In that cause, when we use the newly built xsltproc to
generate headers, one of them is corrupted and results in a build
failure when we try to compile with that header.  Adding the length
check avoids evaluating "$shift>0" when $shift is blank

This problem is only a build failure.

 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.1.8 RC2 build broken when configured with --without-fonts

[Don Lewis]

On 12 Oct, Matthias Seidel wrote:
> Hi Don,
> 
> Am 12.10.20 um 00:49 schrieb Don Lewis:
>> On 10 Oct, Don Lewis wrote:
>>> On 10 Oct, Matthias Seidel wrote:
>>>> Hi Don,
>>>>
>>>> Am 10.10.20 um 13:30 schrieb Don Lewis:
>>>>> On 10 Oct, Matthias Seidel wrote:
>>>>>> Hi Don,
>>>>>>
>>>>>> Am 10.10.20 um 13:04 schrieb Don Lewis:
>>>>>>> On  9 Oct, Dave Fisher wrote:
>>>>>>>> It’s a guess, but which Java are you using?
>>>>>>> OpenJDK 1.8.0_252
>>>>>> What happens if you build with Java 7?
>>>>>>>> Some of those look like java doc errors.
>>>>>>> Yes, this looks a lot like the --enable-odk problem with Java 8, but
>>>>>>> those fixes were merged to AOO418 and I am not using --enable-odk.
>>>>>> I don't think there is --enable-odk. What we have is --disable-odk.
>>>>> I suspect that --enable-odk is accepted and doesn't change the default.
>>>>> Regardless, I just checked and I'm passing --disable-odk to configure.
>>>> Thanks for the clarification.
>>>>
>>>> In that case Javadoc should not be involved at all?
>>> One would think, but the errors are being flagged in comments, which is
>>> what javadoc looks at.
>>>
>>> 4.1.7 builds fine with the same version of java as long as I configure
>>> with --disable-odk.
>> Digging into the logs, I see javadoc stuff happening whether or not
>> --disable-odk is specified, but the errors seem to get ignored.
>>
>> I do see another error with my FreeBSD build of 4.1.8:
>>
>> : && 
>> LD_LIBRARY_PATH=/wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.
>> 8/main/solver/418/unxfbsdx.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} 
>> ../../
>> ../unxfbsdx.pro/bin/gencoll_rule dz_charset.txt 
>> ../../../unxfbsdx.pro/misc/colla
>> tor_dz_charset.cxx dz_charset
>> /wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.8/main/i18npool/unxfbsdx.
>> pro/bin/gencoll_rule: Undefined symbol "_ZN7icu_4_013UnicodeStringC1EPKt"
>> dmake:  Error code 1, while making 
>> '../../../unxfbsdx.pro/misc/collator_dz_chars
>> et.cxx'
>>
>> Hmn ... it looks like gencoll_rule rule is picking up the system icu
>> libraries rather than the bundled icu libraries.  Earlier I see some
>> linking errors that seem to get ignored:
> 
> A quick guess:
> 
> https://bz.apache.org/ooo/show_bug.cgi?id=125371

Nope, the rpath is right.

This turns out to be a bug in the FreeBSD port.  Until recently, the
FreeBSD port used the system python.  Python 2 is now deprecated on
FreeBSD and will be removed by the end of the year, so a while back I
switched the port to use the bundled python.  When I did this, I didn't
notice that python wants to use readline, which got flagged.  When I
added the readline dependency, that caused -L/usr/local/lib to be added
to the value of LDFLAGS that gets passed to build through the
environment.  That in turn mucks up the library search order and causes
system libraries to be preferred to our bundled libraries.

I added the readline dependency at the same time as I was working on the
patch for the missing fc_local file, which is why things suddenly and
unexpectedly broke for me.

Sorry for the noise.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.1.8 RC2 build broken when configured with --without-fonts

[Don Lewis]

On 10 Oct, Don Lewis wrote:
> On 10 Oct, Matthias Seidel wrote:
>> Hi Don,
>> 
>> Am 10.10.20 um 13:30 schrieb Don Lewis:
>>> On 10 Oct, Matthias Seidel wrote:
>>>> Hi Don,
>>>>
>>>> Am 10.10.20 um 13:04 schrieb Don Lewis:
>>>>> On  9 Oct, Dave Fisher wrote:
>>>>>> It’s a guess, but which Java are you using?
>>>>> OpenJDK 1.8.0_252
>>>> What happens if you build with Java 7?
>>>>>> Some of those look like java doc errors.
>>>>> Yes, this looks a lot like the --enable-odk problem with Java 8, but
>>>>> those fixes were merged to AOO418 and I am not using --enable-odk.
>>>> I don't think there is --enable-odk. What we have is --disable-odk.
>>> I suspect that --enable-odk is accepted and doesn't change the default.
>>> Regardless, I just checked and I'm passing --disable-odk to configure.
>> 
>> Thanks for the clarification.
>> 
>> In that case Javadoc should not be involved at all?
> 
> One would think, but the errors are being flagged in comments, which is
> what javadoc looks at.
> 
> 4.1.7 builds fine with the same version of java as long as I configure
> with --disable-odk.

Digging into the logs, I see javadoc stuff happening whether or not
--disable-odk is specified, but the errors seem to get ignored.

I do see another error with my FreeBSD build of 4.1.8:

: && LD_LIBRARY_PATH=/wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.
8/main/solver/418/unxfbsdx.pro/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} ../../
../unxfbsdx.pro/bin/gencoll_rule dz_charset.txt ../../../unxfbsdx.pro/misc/colla
tor_dz_charset.cxx dz_charset
/wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.8/main/i18npool/unxfbsdx.
pro/bin/gencoll_rule: Undefined symbol "_ZN7icu_4_013UnicodeStringC1EPKt"
dmake:  Error code 1, while making '../../../unxfbsdx.pro/misc/collator_dz_chars
et.cxx'

Hmn ... it looks like gencoll_rule rule is picking up the system icu
libraries rather than the bundled icu libraries.  Earlier I see some
linking errors that seem to get ignored:

c++ -Wl,-z,combreloc -L/usr/local/lib -Wl,-rpath,/usr/local/lib 
-fstack-protector-strong -Wl,-z,defs -Wl,-export-dynamic -Wl,--noinhibit-exec 
-Wl,-rpath-link,../.
./unxfbsdx.pro/lib:/wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.8/main/solver/418/unxfbsdx.pro/lib:/lib:/usr/lib
 -L../../unxfbsdx.pro/lib -L../lib -L/wr
kdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.8/main/solenv/unxfbsdx/lib 
-L/wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.8/main/solver/418/unxfbsdx
.pro/lib 
-L/wrkdirs/usr/ports/editors/openoffice-418/work/aoo-4.1.8/main/solenv/unxfbsdx/lib
 -L/usr/local/openjdk8/lib -L/usr/local/openjdk8/jre/lib/amd64 -L/usr/
local/openjdk8/jre/lib/amd64/server 
-L/usr/local/openjdk8/jre/lib/amd64/native_threads -L/usr/local/lib 
../../unxfbsdx.pro/obj/gencoll_rule.o \
-Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive -luno_sal -licui18n 
-licuuc -licudata -Wl,--as-needed -pthread -lm -Wl,--no-as-needed  -o 
../../unxfbsdx.pro
/bin/gencoll_rule
../../unxfbsdx.pro/obj/gencoll_rule.o: In function `main':
gencoll_rule.cxx:(.text+0x355): undefined reference to 
`icu_4_0::UnicodeString::UnicodeString(unsigned short const*)'
gencoll_rule.cxx:(.text+0x36b): undefined reference to 
`icu_4_0::RuleBasedCollator::RuleBasedCollator(icu_4_0::UnicodeString const&, 
UErrorCode&)'
gencoll_rule.cxx:(.text+0x377): undefined reference to 
`icu_4_0::UnicodeString::~UnicodeString()'
gencoll_rule.cxx:(.text+0x3ac): undefined reference to 
`icu_4_0::RuleBasedCollator::cloneRuleData(int&, UErrorCode&)'
gencoll_rule.cxx:(.text+0x3f8): undefined reference to `uprv_free_4_0'
gencoll_rule.cxx:(.text+0x48e): undefined reference to 
`icu_4_0::UnicodeString::~UnicodeString()'
-rwxr-xr-x  1 nobody  wheel  18342 Oct 11 19:33 
../../unxfbsdx.pro/bin/gencoll_rule

There are differences in the compiler command line.  The working 4.1.7
version:
c++ -Wl,-z,combreloc -Wl,-rpath,/usr/local/lib -fstack-protector-strong 
-Wl,-z,defs -Wl,-export-dynamic -Wl,--noinhibit-exec 
-Wl,-rpath-link,../../unxfbsdx.pro/li
b:/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.7/main/solver/417/unxfbsdx.pro/lib:/lib:/usr/lib
 -L../../unxfbsdx.pro/lib -L../lib -L/wrkdirs/usr/ports/edi
tors/openoffice-4/work/aoo-4.1.7/main/solenv/unxfbsdx/lib 
-L/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.7/main/solver/417/unxfbsdx.pro/lib
 -L/wrkdirs/usr
/ports/editors/openoffice-4/work/aoo-4.1.7/main/solenv/unxfbsdx/lib 
-L/usr/local/openjdk8/lib -L/usr/local/openjdk8/jre/lib/amd64 
-L/usr/local/openjdk8/jre/lib/am
d64/server -L/usr/local/openjdk8/jre/lib/amd64/native_threads -L/usr/local/lib 
../../unxfbsdx.pro/obj/gencoll_rule.o \
-Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive -luno_sal -licui18n 
-

Re: error in instsetoo_native module

[Don Lewis]

On 11 Oct, Matthias Seidel wrote:
> Hi Peter,
> 
> **
> ERROR: ERROR: Missing files
> in function: remove_Files_Without_Sourcedirectory
> **
> 
> That looks like the problem Don is having on FreeBSD.
> 
> What happens if you build without --without-fonts?
> 
> Regards,
> 
>    Matthias
> 
> 
> Am 11.10.20 um 23:02 schrieb Peter Kovacs:
>> I have an error on my build. I have no idea what to do. It seems like
>> the issue turns up at the packaging side.
>>
>> All info are appreciated. Maybe it is something with my build
>> environment.
>>
>> For reference my config looks like:
>>
>> ./configure \
>>     --with-dmake-path=/home/legine/workspace/dmake/bin/bin/dmake \
>>  --with-epm=/home/legine/workspace/epm/bin/bin/epm \
>>     --with-lang="${LANGS}" \
>>     --with-jdk-home=${jdkhome} \
>>     --with-package-format="installed" \
>>     --with-vendor="Petko Testbuild"\
>>     --with-build-version="aoo4ever-$(date +"%Y-%m-%d %H:%M") - `uname
>> -sm`\n ${GitHash}" \
>>     --with-system-stdlibs \
>>     --enable-crashdump=yes \
>>     --enable-category-b \
>>     --enable-beanshell \
>>     --enable-wiki-publisher \
>>     --enable-bundled-dictionaries \
>>     --enable-opengl  \
>>     --enable-dbus  \
>>     --without-junit \
>>     --without-stlport \
>>     --disable-odk \
>>     --without-fonts \
>>
>> my error output in the Log:
>>
>> build -- version: 275224
>>
>>
>> =
>> Building module instsetoo_native
>> =
>>
>> Entering
>> /home/legine/workspace/AOO/gitbox/main/instsetoo_native/inc_openoffice/windows/msi_languages
>>
>>
>> Entering
>> /home/legine/workspace/AOO/gitbox/main/instsetoo_native/inc_openoffice/unix
>>
>>
>> Entering /home/legine/workspace/AOO/gitbox/main/instsetoo_native/util
>>
>> ... checking environment variables ...
>>
>> 
>> make_installer.pl, version 1.0
>> Product list file: ../util/openoffice.lst
>> Taking setup script from solver
>> Unpackpath:
>> /home/legine/workspace/AOO/gitbox/main/instsetoo_native/util/../unxlngx6.pro
>> Compiler: unxlngx6
>> Product: Apache_OpenOffice
>> BuildID: 9802
>> Build: AOO418
>> No minor set
>> Product version
>> Using default installpath
>> Package format: installed
>> msi templatepath:
>> /home/legine/workspace/AOO/gitbox/main/instsetoo_native/util/../unxlngx6.pro/misc/openoffice/msi_templates
>> msi template path will be ignored for non Windows builds!
>> msi languagepath:
>> /home/legine/workspace/AOO/gitbox/main/instsetoo_native/util/../unxlngx6.pro/misc/win_ulffiles
>> msi language path will be ignored for non Windows builds!
>> Calling epm
>> Stripping files
>> Unzip ARCHIVE files
>> Languages: en-US
>> 
>> ... checking required files ...
>> .. searching zip ...
>>     Found: /usr/bin/zip
>> ... analyzing ../util/openoffice.lst ...
>> ... reading include pathes ...
>> ... analyzing script:
>> /home/legine/workspace/AOO/gitbox/main/solver/418/unxlngx6.pro/bin/setup_osl.ins
>> ...
>> ... analyzing script:
>> /home/legine/workspace/AOO/gitbox/main/solver/418/unxlngx6.pro/bin/setup_osl.ins
>> ...
>> ... analyzing directories ...
>> ... analyzing files ...
>> ... analyzing scpactions ...
>> ... analyzing shortcuts ...
>> ... analyzing unix links ...
>> ... analyzing profile ...
>> ... analyzing profileitems ...
>> ... analyzing modules ...
>> 
>> ... languages en-US ...
>> ... analyzing files ...
>> preparing 1 extension blob for language en-US:
>>     dict-en.oxt
>> preparing 0 bundled extensions for language en-US:
>> ERROR: The following files could not be found:
>> ERROR: File not found: fc_local.conf
>> ... cleaning the output tree ...
>> ... removing directory /tmp/ooopackaging/i_190831602449324 ...
>> Error: ERROR: Missing files
>>
>> **
>> ERROR: ERROR: Missing files
>> in function: remove_Files_Without_Sourcedirectory
>> **
>> in function: remove_Files_Without_Sourcedirectorystopping log at Sun
>> Oct 11 22:48:45 2020
>> dmake:  Error code 255, while making 'openoffice_en-US.installed'
>>
>> 1 module(s):
>>     instsetoo_native
>> need(s) to be rebuilt
>>
>> Reason(s):
>>
>> ERROR: error 65280 occurred while making
>> /home/legine/workspace/AOO/gitbox/main/instsetoo_native/util
>>
>> When you have fixed the errors in that module you can resume the build
>> by running:
>>
>>     build --all:instsetoo_native

Yes sounds like the same problem.  I've got a patch and will put
together a pull request shortly.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building 4.1.8-RC2 - packaging issues

[Don Lewis]

On 11 Oct, Andrea Pescetti wrote:
> I've built the 4.1.8-RC2 sources from
> https://dist.apache.org/repos/dist/dev/openoffice/4.1.8-RC2/source/
> on a new CentOS 7 VM and generated "installed" (not packaged), RPM and 
> DEB builds that I tested on a variety of Fedora and Ubuntu systems.
> 
> All good, for the most part. I'm still catching up with e-mails so I 
> didn't test anything specific to 4.1.8, just general usage. I have news 
> on the "General error" on Ubuntu too, but I'll expand on this in the 
> relevant thread.
> 
> But I'd like to highlight two issues occurring in the last stage of the 
> build, i.e., when we produce the RPM/DEB packages.
> 
> 1) Jim's EPM installed as per
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#CentOS_7_for_AOO_4.2.x_and_later
> didn't work for me. I got
> 
> Error: ERROR: More than one new package in directory
> 
> Configuring with
> 
> ... 
> --with-epm-url=http://sourceforge.net/projects/oooextras.mirror/files/epm-3.7.tar.gz
> 
> did work instead, so I'd like to know if people who used the wiki 
> instructions
> 
> $ wget https://github.com/jimjag/epm/archive/epm-4.4.2.tar.gz
> $ # (extract the archive)
> $ cd epm-epm-4.4.2
> $ ./configure --prefix=/usr/local --enable-aoo; make install
> 
> had better luck. Or maybe the new EPM is to be used for 4.2.x builds only?
> 
> 2) Something seems wrong here:
> 
> https://github.com/apache/openoffice/blob/AOO418/main/solenv/bin/modules/RepoRevision.pm#L78
> 
> We populate the "Rev." section of the About dialog based on version 
> control, so for a tarball (no Git, no SVN) this should result in 
> "unknown-rev"; but it doesn't and Git is called instead, returning an 
> error message.
> 
> To my purpose I simply used a hardcoded string and completed the build, 
> but it should be checked better: the official tarball is not a git clone 
> and this will always result in a (non-blocking) error message if someone 
> builds from it.

I thought that the source tarball was supposed to include an artifact
containing the git revision info.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.1.8 RC2 build broken when configured with --without-fonts

[Don Lewis]

On 10 Oct, Matthias Seidel wrote:
> Hi Don,
> 
> Am 10.10.20 um 13:30 schrieb Don Lewis:
>> On 10 Oct, Matthias Seidel wrote:
>>> Hi Don,
>>>
>>> Am 10.10.20 um 13:04 schrieb Don Lewis:
>>>> On  9 Oct, Dave Fisher wrote:
>>>>> It’s a guess, but which Java are you using?
>>>> OpenJDK 1.8.0_252
>>> What happens if you build with Java 7?
>>>>> Some of those look like java doc errors.
>>>> Yes, this looks a lot like the --enable-odk problem with Java 8, but
>>>> those fixes were merged to AOO418 and I am not using --enable-odk.
>>> I don't think there is --enable-odk. What we have is --disable-odk.
>> I suspect that --enable-odk is accepted and doesn't change the default.
>> Regardless, I just checked and I'm passing --disable-odk to configure.
> 
> Thanks for the clarification.
> 
> In that case Javadoc should not be involved at all?

One would think, but the errors are being flagged in comments, which is
what javadoc looks at.

4.1.7 builds fine with the same version of java as long as I configure
with --disable-odk.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.1.8 RC2 build broken when configured with --without-fonts

[Don Lewis]

On 10 Oct, Matthias Seidel wrote:
> Hi Don,
> 
> Am 10.10.20 um 13:04 schrieb Don Lewis:
>> On  9 Oct, Dave Fisher wrote:
>>> It’s a guess, but which Java are you using?
>> OpenJDK 1.8.0_252
> What happens if you build with Java 7?
>>
>>> Some of those look like java doc errors.
>> Yes, this looks a lot like the --enable-odk problem with Java 8, but
>> those fixes were merged to AOO418 and I am not using --enable-odk.
> 
> I don't think there is --enable-odk. What we have is --disable-odk.

I suspect that --enable-odk is accepted and doesn't change the default.
Regardless, I just checked and I'm passing --disable-odk to configure.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: 4.1.8 RC2 build broken when configured with --without-fonts

[Don Lewis]

On  9 Oct, Dave Fisher wrote:
> It’s a guess, but which Java are you using?

OpenJDK 1.8.0_252

> Some of those look like java doc errors.

Yes, this looks a lot like the --enable-odk problem with Java 8, but
those fixes were merged to AOO418 and I am not using --enable-odk.

It acts like javadoc is being run on some files that have never been run
through javadoc before in recent history.  I have no idea what might be
triggering that and why it suddenly started happening.

> Regards,
> Dave
> 
> Sent from my iPhone
> 
>> On Oct 9, 2020, at 6:08 PM, Don Lewis  wrote:
>> 
>> I started working on the FreeBSD port for 4.1.8.  Unlike the the other
>> ports, the FreeBSD port doesn't bundle fonts with the package.  Instead
>> it uses fonts from the system, installing them separately if necessary.
>> To do this, it configures with the --without-fonts option.  This 4.1.8
>> RC2 fails with this error:
>> 
>> preparing 0 bundled extensions for language en-US:
>> ... analyzing files with flag ARCHIVE ...
>> ... reading include pathes ...
>> ... analyzing script: 
>> /home/dl/openoffice/main/solver/418/unxlngx6.pro/bin/setup_osl.ins ... 
>> ... analyzing script: 
>> /home/dl/openoffice/main/solver/418/unxlngx6.pro/bin/setup_osl.ins ... 
>> ... analyzing directories ... 
>> ... analyzing files ... 
>> ... analyzing scpactions ... 
>> ... analyzing shortcuts ... 
>> ... analyzing unix links ... 
>> ... analyzing profile ... 
>> ... analyzing profileitems ... 
>> ... analyzing modules ... 
>> 
>> ... languages en-US ... 
>> 
>> **
>> ERROR: ERROR: Missing files
>> in function: remove_Files_Without_Sourcedirectory
>> **
>> ... analyzing files ...
>> preparing 1 extension blob for language en-US:
>>dict-en.oxt
>> preparing 0 bundled extensions for language en-US:
>> ERROR: The following files could not be found:
>> ERROR: File not found: fc_local.conf
>> ... cleaning the output tree ...
>> ... removing directory /tmp/ooopackaging/i_199031602279361 ...
>> Error: ERROR: Missing files
>> in function: remove_Files_Without_Sourcedirectorystopping log at Fri Oct  9 
>> 14:36:03 2020
>> 
>> This can be reproduced on Linux.
>> 
>> 
>> 
>> I started working on a patch but then ran into another failure much
>> earlier in the build that now happens either with without my patch.
>> 
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Selection.java:94:
>>  warning: no @param for p
>>public void setActiveCell(Point p) {
>>^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:48:
>>  warning: no description for @param
>> * @param str
>>   ^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:50:
>>  warning: no @throws for java.io.IOException
>>public StringValue(String str) throws IOException {
>>   ^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:61:
>>  warning: no @throws for java.io.IOException
>>public StringValue(InputStream is) throws IOException {
>>   ^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:109:
>>  warning: no @throws for java.io.IOException
>>public String getString() throws IOException {
>>  ^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Workbook.java:361:
>>  error: invalid use of @return
>> * @return name the name of the Worksheet to be added
>>   ^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Workbook.java:375:
>>  error: invalid use of @return
>> * @return the name of the Worksheet to be added
>>   ^
>> /wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Worksheet.ja

4.1.8 RC2 build broken when configured with --without-fonts

[Don Lewis]

I started working on the FreeBSD port for 4.1.8.  Unlike the the other
ports, the FreeBSD port doesn't bundle fonts with the package.  Instead
it uses fonts from the system, installing them separately if necessary.
To do this, it configures with the --without-fonts option.  This 4.1.8
RC2 fails with this error:

preparing 0 bundled extensions for language en-US:
... analyzing files with flag ARCHIVE ...
... reading include pathes ...
... analyzing script: 
/home/dl/openoffice/main/solver/418/unxlngx6.pro/bin/setup_osl.ins ... 
... analyzing script: 
/home/dl/openoffice/main/solver/418/unxlngx6.pro/bin/setup_osl.ins ... 
... analyzing directories ... 
... analyzing files ... 
... analyzing scpactions ... 
... analyzing shortcuts ... 
... analyzing unix links ... 
... analyzing profile ... 
... analyzing profileitems ... 
... analyzing modules ... 

... languages en-US ... 

**
ERROR: ERROR: Missing files
in function: remove_Files_Without_Sourcedirectory
**
... analyzing files ...
preparing 1 extension blob for language en-US:
dict-en.oxt
preparing 0 bundled extensions for language en-US:
ERROR: The following files could not be found: 
ERROR: File not found: fc_local.conf
... cleaning the output tree ...
... removing directory /tmp/ooopackaging/i_199031602279361 ...
Error: ERROR: Missing files
in function: remove_Files_Without_Sourcedirectorystopping log at Fri Oct  9 
14:36:03 2020

This can be reproduced on Linux.



I started working on a patch but then ran into another failure much
earlier in the build that now happens either with without my patch.

/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Selection.java:94:
 warning: no @param for p
public void setActiveCell(Point p) {
^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:48:
 warning: no description for @param
 * @param str
   ^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:50:
 warning: no @throws for java.io.IOException
public StringValue(String str) throws IOException {
   ^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:61:
 warning: no @throws for java.io.IOException
public StringValue(InputStream is) throws IOException {
   ^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/StringValue.java:109:
 warning: no @throws for java.io.IOException
public String getString() throws IOException {
  ^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Workbook.java:361:
 error: invalid use of @return
 * @return name the name of the Worksheet to be added
   ^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Workbook.java:375:
 error: invalid use of @return
 * @return the name of the Worksheet to be added
   ^
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/pexcel/java/org/openoffice/xmerge/converter/xml/sxc/pexcel/records/Worksheet.java:253:
 error: invalid use of @return
 * @return an Enumeration to the ColInfo's
   ^
Building index for all the packages and classes...
Building index for all classes...
Generating 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/unxfbsdx.pro/class/javadoc/help-doc.html...
15 errors
100 warnings

main:

BUILD SUCCESSFUL
Total time: 2 seconds

Entering 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/xmerge/source/activesync

xmerge deliver
deliver -- version: 275594
COPY: build.lst -> 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/solver/418/unxfbsdx.pro/inc/xmerge/build.lst
COPY: ../unxfbsdx.pro/class/xmerge.jar -> 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/solver/418/unxfbsdx.pro/bin/xmerge.jar
COPY: ../unxfbsdx.pro/class/pexcel.jar -> 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/solver/418/unxfbsdx.pro/bin/pexcel.jar
COPY: ../unxfbsdx.pro/class/htmlsoff.jar -> 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/solver/418/unxfbsdx.pro/bin/htmlsoff.jar
COPY: ../unxfbsdx.pro/class/aportisdoc.jar -> 
/wrkdirs/usr/ports/editors/openoffice-4/work/aoo-4.1.8/main/solver/418/unxfbsdx.pro/bin/aportisdoc.jar
COPY: ../unxfbsdx.pro/class/XMergeBridge.jar 

how to download RC2?

[Don Lewis]

I want to download the source tarball for RC2, but this page:
  
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-fullsets
isn't helpful.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [openoffice] branch AOO418 updated: Fix broken compile for older Linux... disable HW accel just as we used to do before

[Don Lewis]

On  6 Oct, j...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> jim pushed a commit to branch AOO418
> in repository https://gitbox.apache.org/repos/asf/openoffice.git
> 
> 
> The following commit(s) were added to refs/heads/AOO418 by this push:
>  new 0a99449  Fix broken compile for older Linux... disable HW accel just 
> as we used to do before
> 0a99449 is described below

This is a bit misleading.  The code compiles fine and works properly on
CentOS 5.  It just won't run on older hardware that doesn't have the new
crypto instructions.  I didn't catch it since I built and tested the
code on a CentOS 5 VM running on a Ryzen.

Good catch.  The next nss upgrade probably has the same problem.

> commit 0a994498bd0b70dfacbfd49f6470cce09e547165
> Author: Jim Jagielski 
> AuthorDate: Tue Oct 6 15:42:08 2020 -0400
> 
> Fix broken compile for older Linux... disable HW accel just as we used to 
> do before
> ---
>  main/nss/nss_linux.patch | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/main/nss/nss_linux.patch b/main/nss/nss_linux.patch
> index 9d768b2..50c27a4 100644
> --- a/main/nss/nss_linux.patch
> +++ b/main/nss/nss_linux.patch
> @@ -12,3 +12,18 @@ diff -ur misc/nss-3.25/nss/lib/freebl/Makefile 
> misc/build/nss-3.25/nss/lib/freeb
>   EXTRA_SRCS += intel-gcm-wrap.c
>   ifeq ($(CLANG_CL),1)
>   INTEL_GCM_CLANG_CL = 1
> +@@ -221,10 +221,10 @@
> + DEFINES += -DMP_IS_LITTLE_ENDIAN
> + #   DEFINES += -DMPI_AMD64_ADD
> + # comment the next four lines to turn off Intel HW acceleration.
> +-DEFINES += -DUSE_HW_AES -DINTEL_GCM
> +-ASFILES += intel-aes.s intel-gcm.s
> +-EXTRA_SRCS += intel-gcm-wrap.c
> +-INTEL_GCM = 1
> ++#DEFINES += -DUSE_HW_AES -DINTEL_GCM
> ++#ASFILES += intel-aes.s intel-gcm.s
> ++#EXTRA_SRCS += intel-gcm-wrap.c
> ++#INTEL_GCM = 1
> + MPI_SRCS += mpi_amd64.c mp_comba.c
> + endif
> + ifeq ($(CPU_ARCH),x86)
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418 cherry picks

[Don Lewis]

On  6 Oct, Jim Jagielski wrote:
> Thanks! Since these are relatively new, I think that this can hold for 4.1.9

I'd at least like to get the nss update into trunk/AOO42X where it can
soak for a while.

>> On Oct 6, 2020, at 12:19 PM, Don Lewis  wrote:
>> 
>> On  6 Oct, Jim Jagielski wrote:
>>> OK... as expected, it fails on macOS.
>>> 
>>> 2 things I see: in the nss.patch file there is a line:
>>> 
>>>Only in misc/build/nss-3.39/nss/coreconf: Darwin.mk.rej
>>> 
>>> So I'm wondering if the patch file itself or maybe even the whole pull 
>>> request is borked.
>>> 
>>> Also, we need to force 'g++' on the macOS build to include '-std=c++11'
>> 
>> I missed that the patch to Darwin.mk was rejected when I applied the
>> pre-update version of the patch.  I regenerated nss.patch, so these
>> issues should be fixed now, or at least should be much better.
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418 cherry picks

[Don Lewis]

On  6 Oct, Jim Jagielski wrote:
> OK... as expected, it fails on macOS.
> 
> 2 things I see: in the nss.patch file there is a line:
> 
> Only in misc/build/nss-3.39/nss/coreconf: Darwin.mk.rej
> 
> So I'm wondering if the patch file itself or maybe even the whole pull 
> request is borked.
> 
> Also, we need to force 'g++' on the macOS build to include '-std=c++11'

I missed that the patch to Darwin.mk was rejected when I applied the
pre-update version of the patch.  I regenerated nss.patch, so these
issues should be fixed now, or at least should be much better.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418 cherry picks

[Don Lewis]

Any progress on nss?

On 30 Sep, Jim Jagielski wrote:
> I'll see how the build on macOS goes, but likely won't be able to get to it 
> until Monday.
> 
>> On Sep 29, 2020, at 2:52 PM, Don Lewis  wrote:
>> 
>> On 29 Sep, Matthias Seidel wrote:
>>> Hi Don,
>>> 
>>> Am 26.09.20 um 23:47 schrieb Don Lewis:
>>>> On 26 Sep, Matthias Seidel wrote:
>>>>> Hi all,
>>>>> 
>>>>> Am 25.09.20 um 18:05 schrieb Matthias Seidel:
>>>>>> Am 25.09.20 um 14:01 schrieb Jim Jagielski:
>>>>>>> That looks quite a bit more straightforward :-)
>>>>>> Let's wait for Don's PR, this is only a minor update from Python 2.7.17
>>>>>> to 2.7.18.
>>>>> Merged now...
>>>>> 
>>>>> Unless Don wants to add something for the Java detection I would think
>>>>> we are pretty close to a release candidate?
>>>> I've got another nss upgrade in the works as well as a small serf bug
>>>> fix.
>>> 
>>> OK, if that can be done quick *and* safe?
>> 
>> nss is somewhat risky.  We've had problems with upgrading it in the
>> past, primarily with MacOS.  It does fix a fairly important CVE, though
>> I don't know if it potentially affects our usage of nss.  I just
>> submitted a pull request.
>> 
>> Serf should be fairly quick.  It's just a couple of patches
>> cherry-picked from upstream to fix a CVE.
>> 
>> There are also a few new libxml2 CVEs, but not a new release of the
>> library.  They can be fixed with some upstream cherry picks.
>> 
>>> Otherwise I doubt that we have a release in the next 2 weeks... ;-)
>>> 
>>> Regards,
>>> 
>>>Matthias
>>> 
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>> 
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org 
>> <mailto:dev-unsubscr...@openoffice.apache.org>
>> For additional commands, e-mail: dev-h...@openoffice.apache.org 
>> <mailto:dev-h...@openoffice.apache.org>


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [openoffice] branch trunk updated: It seems we need YYDEBUG to compile main/connectivity now.

[Don Lewis]

On  5 Oct, Damjan Jovanovic wrote:
> On Mon, Oct 5, 2020 at 8:08 AM Don Lewis  wrote:
> 
>> On  5 Oct, dam...@apache.org wrote:
>> > This is an automated email from the ASF dual-hosted git repository.
>> >
>> > damjan pushed a commit to branch trunk
>> > in repository https://gitbox.apache.org/repos/asf/openoffice.git
>> >
>> >
>> > The following commit(s) were added to refs/heads/trunk by this push:
>> >  new 9b7130f  It seems we need YYDEBUG to compile main/connectivity
>> now.
>> > 9b7130f is described below
>>
>> I haven't seen that here on either Linux or Windows.
>>
>>
>>
> Possibly only happens with my --enable-dbgutil --enable-symbols or other
> flags.

Of those two, --enable-dbgutil would be my guess, though I'm pretty sure
I've enabled that in the past and not run into this issue.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Fwd: [libexpat/libexpat] Release R_2_2_10 - 2.2.10

[Don Lewis]

On  3 Oct, Matthias Seidel wrote:
> Hi all,
> 
> Libexpat has been updated!
> 
> Regards,
> 
>    Matthias
> 
> 
> 
>  Weitergeleitete Nachricht 
> Betreff:  [libexpat/libexpat] Release R_2_2_10 - 2.2.10
> Datum:Sat, 03 Oct 2020 11:35:44 -0700
> Von:  Sebastian Pipping 
> Antwort an:   libexpat/libexpat 
> An:   libexpat/libexpat 
> Kopie (CC):   Subscribed 
> 
> 
> 
>   2.2.10 
> 
> Repository: libexpat/libexpat  ·
> Tag: R_2_2_10  ·
> Commit: 162e16b
> 
> · Released by: hartwork 
> 
> Original changelog
> 
> 
> —
> 
> This release has 11 assets:
> 
>   * expat-2.2.10.tar.bz2
>   * expat-2.2.10.tar.bz2.asc
>   * expat-2.2.10.tar.gz
>   * expat-2.2.10.tar.gz.asc
>   * expat-2.2.10.tar.lz
>   * expat-2.2.10.tar.lz.asc
>   * expat-2.2.10.tar.xz
>   * expat-2.2.10.tar.xz.asc
>   * expat-win32bin-2.2.10.exe
>   * Source code (zip)
>   * Source code (tar.gz)
> 
> Visit the release page
>  to download
> them.

I've updated trunk and AOO42X.  Any thoughts on AOO418?


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [openoffice] branch trunk updated: It seems we need YYDEBUG to compile main/connectivity now.

[Don Lewis]

On  5 Oct, dam...@apache.org wrote:
> This is an automated email from the ASF dual-hosted git repository.
> 
> damjan pushed a commit to branch trunk
> in repository https://gitbox.apache.org/repos/asf/openoffice.git
> 
> 
> The following commit(s) were added to refs/heads/trunk by this push:
>  new 9b7130f  It seems we need YYDEBUG to compile main/connectivity now.
> 9b7130f is described below

I haven't seen that here on either Linux or Windows.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418 cherry picks

[Don Lewis]

I've got everything on my list for AOO418 in the queue:

  * Fix for old java detection when building with new java
Set java compilation target to version 1.5 #101
https://github.com/apache/openoffice/pull/101

  * Bug fixes from upstream for bundled libxml2 and serf modules
Libxml+serf 418 #102
https://github.com/apache/openoffice/pull/102

  * Upgrade to a newer bundled nss
Nssupgrade - Upgrade bundled nss to nss-3.39-with-nspr-4.20 #100
https://github.com/apache/openoffice/pull/100

The first two have been committed to trunk and AOO42X.  The AOO418
changes have been lightly tested on Debian 9, Windows 7, and CentOS 5.

The last pull request has not yet been merged to trunk.  The changes
have been tested on Debian 9, Windows 7, and CentOS 7.  Upgrades to NSS
have been problematic in the past, especially on MacOS.  This module is
used for document signing and signature checking.


 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building AOO under Debian9

[Don Lewis]

On 30 Sep, Dr. Michael Stehmann wrote:
> Hello Don,
> 
> in configure.sh I had this line :
> 
> --with-build-version="aoo42x-$(date +"%Y-%m-%d %H:%M") - `uname -sm`\n
> ${GitHash}"
> 
> Because I want to have the corresponding git hash I built, I need the
> output in two lines.

Instead of \n, try n.  That forces the environment variable to
contain a literal \n, which should get passed as a compiler preprocessor
symbol definition, and the compiler will turn the \n into a newline.  I
don't know how that interacts with the About dialog, though.

This is one more level of escaping than I think should be necessary, but
\\n didn't seem to help.

> Thanks for your help
> 
> Kind regards
> 
> Mechtilde
> 
> Am 30.09.20 um 08:38 schrieb Don Lewis:
>> On 30 Sep, Mechtilde wrote:
>>> Hello,
>>>
>>> I set up a recent build environment with Debian 9.
>>>
>>> I have got the same error message again:
>>>
>>> ~/openoffice/main/instsetoo_native$ build --from cui
>>> build -- version: -
>>>
>>>
>>> =
>>> Building module cui
>>> =
>>>
>>> Entering /home/mechtilde/openoffice/main/cui/prj
>>>
>>> cd .. && make -s -r -j1   && make -s -r deliverlog
>>> /home/mechtilde/openoffice/main/cui/Library_cui.mk:37: *** missing
>>> separator.  Stop.
>>> dmake:  Error code 2, while making 'all'
>>>
>>> 1 module(s):
>>> cui
>>> need(s) to be rebuilt
>>>
>>> Reason(s):
>>>
>>> ERROR: error 65280 occurred while making
>>> /home/mechtilde/openoffice/main/cui/prj
>>>
>>> When you have fixed the errors in that module you can resume the build
>>> by running:
>>>
>>> I also attach my file LinuxX86-64Env.Set.sh.
>>>
>>> Can someone help me to get a proper build environment.
>>>
>>> Kind regards
>>>
>>> Mechtilde
>>>
>>> Am 10.11.19 um 22:02 schrieb Ariel Constenla-Haile:
>>>> Hi Mechtilde,
>>>>
>>>> On Sun, Nov 10, 2019 at 5:23 AM Mechtilde  wrote:
>>>>>
>>>>> Hello again,
>>>>>
>>>>> I did a recent git pull AOO42X and try to build it under Debian 9.
>>>>>
>>>>> It didn't build. it fails with error in  main/cui/Library_cui.mk:37
>>>>>
>>>>> If I patched it as before then it builds succesfully.
>>>>>
>>>>> Either we need a switch for Debian 9 and may be newer
>>>>> distribution/versions or we need another fix.
>>>>
>>>> The contents of BUILD_VER_STRING might be the problem, attach your
>>>> LinuxX86-64Env.Set.sh and someone may reproduce the error.
>> 
>> I'm building on Debian 9 and not having any problems.  I just did a
>> trunk build and in my LinuxX86-64Env.Set.sh I see:
>> 
>> $ grep BUILD_VER_STRING LinuxX86-64Env.Set.sh | head -1
>> BUILD_VER_STRING="2020-09-29 22:09:35 (Tue, 29 Sep 2020) - Linux x86_64"
>> 
>> If I look at your LinuxX86-64Env.Set.sh:
>> 
>> %grep BUILD_VER_STRING /tmp/LinuxX86-64Env.Set.sh | head -1
>> BUILD_VER_STRING="aoo42x-2020-09-29 19:11 - Linux x86_64
>> 
>> I see a critical difference.  Mine has " characters around the value,
>> but yours has the leading quote, but no trailing quote.  Looking more
>> closely at the file:
>> 
>> BUILD_VER_STRING="aoo42x-2020-09-29 19:11 - Linux x86_64
>>  "
>> 
>> It looks like a newline is getting embeded into the value somehow.  The
>> rest of the info in the string has other differences as well.
>> 
>> If I check out AOO42X and run autoconf and configure, I see:
>> BUILD_VER_STRING="2020-09-29 23:34:46 (Tue, 29 Sep 2020) - Linux x86_64"
>> 
>> Ah, I'm running configure with this option:
>> --with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b 
>> %Y)") - `uname -sm`${AOO_BUILD_VERSION}"
>> What are you doing here?
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building AOO under Debian9

[Don Lewis]

On 30 Sep, Mechtilde wrote:
> Hello,
> 
> I set up a recent build environment with Debian 9.
> 
> I have got the same error message again:
> 
> ~/openoffice/main/instsetoo_native$ build --from cui
> build -- version: -
> 
> 
> =
> Building module cui
> =
> 
> Entering /home/mechtilde/openoffice/main/cui/prj
> 
> cd .. && make -s -r -j1   && make -s -r deliverlog
> /home/mechtilde/openoffice/main/cui/Library_cui.mk:37: *** missing
> separator.  Stop.
> dmake:  Error code 2, while making 'all'
> 
> 1 module(s):
>   cui
> need(s) to be rebuilt
> 
> Reason(s):
> 
> ERROR: error 65280 occurred while making
> /home/mechtilde/openoffice/main/cui/prj
> 
> When you have fixed the errors in that module you can resume the build
> by running:
> 
> I also attach my file LinuxX86-64Env.Set.sh.
> 
> Can someone help me to get a proper build environment.
> 
> Kind regards
> 
> Mechtilde
> 
> Am 10.11.19 um 22:02 schrieb Ariel Constenla-Haile:
>> Hi Mechtilde,
>> 
>> On Sun, Nov 10, 2019 at 5:23 AM Mechtilde  wrote:
>>>
>>> Hello again,
>>>
>>> I did a recent git pull AOO42X and try to build it under Debian 9.
>>>
>>> It didn't build. it fails with error in  main/cui/Library_cui.mk:37
>>>
>>> If I patched it as before then it builds succesfully.
>>>
>>> Either we need a switch for Debian 9 and may be newer
>>> distribution/versions or we need another fix.
>> 
>> The contents of BUILD_VER_STRING might be the problem, attach your
>> LinuxX86-64Env.Set.sh and someone may reproduce the error.

I'm building on Debian 9 and not having any problems.  I just did a
trunk build and in my LinuxX86-64Env.Set.sh I see:

$ grep BUILD_VER_STRING LinuxX86-64Env.Set.sh | head -1
BUILD_VER_STRING="2020-09-29 22:09:35 (Tue, 29 Sep 2020) - Linux x86_64"

If I look at your LinuxX86-64Env.Set.sh:

%grep BUILD_VER_STRING /tmp/LinuxX86-64Env.Set.sh | head -1
BUILD_VER_STRING="aoo42x-2020-09-29 19:11 - Linux x86_64

I see a critical difference.  Mine has " characters around the value,
but yours has the leading quote, but no trailing quote.  Looking more
closely at the file:

BUILD_VER_STRING="aoo42x-2020-09-29 19:11 - Linux x86_64
 "

It looks like a newline is getting embeded into the value somehow.  The
rest of the info in the string has other differences as well.

If I check out AOO42X and run autoconf and configure, I see:
BUILD_VER_STRING="2020-09-29 23:34:46 (Tue, 29 Sep 2020) - Linux x86_64"

Ah, I'm running configure with this option:
--with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b 
%Y)") - `uname -sm`${AOO_BUILD_VERSION}"
What are you doing here?


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418 cherry picks

[Don Lewis]

On 29 Sep, Matthias Seidel wrote:
> Hi Don,
> 
> Am 26.09.20 um 23:47 schrieb Don Lewis:
>> On 26 Sep, Matthias Seidel wrote:
>>> Hi all,
>>>
>>> Am 25.09.20 um 18:05 schrieb Matthias Seidel:
>>>> Am 25.09.20 um 14:01 schrieb Jim Jagielski:
>>>>> That looks quite a bit more straightforward :-)
>>>> Let's wait for Don's PR, this is only a minor update from Python 2.7.17
>>>> to 2.7.18.
>>> Merged now...
>>>
>>> Unless Don wants to add something for the Java detection I would think
>>> we are pretty close to a release candidate?
>> I've got another nss upgrade in the works as well as a small serf bug
>> fix.
> 
> OK, if that can be done quick *and* safe?

nss is somewhat risky.  We've had problems with upgrading it in the
past, primarily with MacOS.  It does fix a fairly important CVE, though
I don't know if it potentially affects our usage of nss.  I just
submitted a pull request.

Serf should be fairly quick.  It's just a couple of patches
cherry-picked from upstream to fix a CVE.

There are also a few new libxml2 CVEs, but not a new release of the
library.  They can be fixed with some upstream cherry picks.

> Otherwise I doubt that we have a release in the next 2 weeks... ;-)
> 
> Regards,
> 
>    Matthias
> 
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: java detection

[Don Lewis]

On 27 Sep, Matthias Seidel wrote:
> Am 26.09.20 um 23:43 schrieb Don Lewis:
>> On 26 Sep, Matthias Seidel wrote:
>>> Hi Don,
>>>
>>> Is this an easy fix?
>> Yes.  What minimum version should we target?
> 
> The same as in trunk?

Trunk currently compiles to 1.7.  For AOO418 is that old enough, or do
we need to support something older?

> I really don't know... ;-)
> 
>>
>>> Regards,
>>>
>>>    Matthias
>>>
>>> Am 25.09.20 um 22:54 schrieb Don Lewis:
>>>> On 25 Sep, Don Lewis wrote:
>>>>> On 24 Sep, Don Lewis wrote:
>>>>>> I've been looking into the problem where AOO418 can't detect older
>>>>>> versions of java when it is built with a new version of java.  This is a
>>>>>> definite puzzle because the detection is done by the jvmfwk module, and
>>>>>> the code in that module is identical between AOO418 and trunk.  The only
>>>>>> difference is that this module has been changed from dmake to gbuild in
>>>>>> trunk.
>>>>>>
>>>>>> The way that java detection works is that we scan the possible java
>>>>>> locations, and for each we run
>>>>>>   [path to javaa]/java[.exe] -classpath C:\\Program\ Files\\OpenOffice\ 
>>>>>> 4\\program JREProperties
>>>>>> which is supposed to output a bunch of data about that version of java,
>>>>>> which we read and parse.  If that fails, then we decide that version of
>>>>>> java is invalid or broken.
>>>>>>
>>>>>> When I build AOO418 with Java 8 and it tries to detect Java 7, I see
>>>>>> this stack trace sent to stderr:
>>>>>>
>>>>>> java.lang.UnsupportedClassVersionError: JREProperties : Unsupported 
>>>>>> major.minor version 52.0
>>>>>> at java.lang.ClassLoader.defineClass1(Native Method)
>>>>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
>>>>>> at 
>>>>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>>>>>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>>>>>> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>>>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>>>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>>>>>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>>>>>> at 
>>>>>> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
>>>>>> Exception in thread "main"
>>>>>>
>>>>>> The problem is that the JREProperties was compiled with Java 8, which
>>>>>> Java 7 can't use:
>>>>>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 
>>>>>> 4/program/JREProperties.class
>>>>>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: 
>>>>>> compiled Java class data, version 52.0 (Java 1.8)
>>>>>>
>>>>>> If I build trunk with Java 8, I see:
>>>>>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 
>>>>>> 4/program/JREProperties.class
>>>>>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: 
>>>>>> compiled Java class data, version 51.0 (Java 1.7)
>>>>>> That's why we don't see this issue with trunk
>>>>>>
>>>>>> It is possible to use a new java compiler to build for older versions of
>>>>>> java using the --target option, but I don't see any sign that we are
>>>>>> doing so.
>>>>>>
>>>>>> Unfortunately the build is too silent for me to see what is actually
>>>>>> happening during the build.  My suspicion is that somehow the trunk
>>>>>> build is somehow using Java 7 to build.
>>>>> I finally figured out the di

Re: AOO418 cherry picks

[Don Lewis]

On 26 Sep, Matthias Seidel wrote:
> Hi all,
> 
> Am 25.09.20 um 18:05 schrieb Matthias Seidel:
>> Am 25.09.20 um 14:01 schrieb Jim Jagielski:
>>> That looks quite a bit more straightforward :-)
>> Let's wait for Don's PR, this is only a minor update from Python 2.7.17
>> to 2.7.18.
> 
> Merged now...
> 
> Unless Don wants to add something for the Java detection I would think
> we are pretty close to a release candidate?

I've got another nss upgrade in the works as well as a small serf bug
fix.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: java detection

[Don Lewis]

On 26 Sep, Matthias Seidel wrote:
> Hi Don,
> 
> Is this an easy fix?

Yes.  What minimum version should we target?

> Regards,
> 
>    Matthias
> 
> Am 25.09.20 um 22:54 schrieb Don Lewis:
>> On 25 Sep, Don Lewis wrote:
>>> On 24 Sep, Don Lewis wrote:
>>>> I've been looking into the problem where AOO418 can't detect older
>>>> versions of java when it is built with a new version of java.  This is a
>>>> definite puzzle because the detection is done by the jvmfwk module, and
>>>> the code in that module is identical between AOO418 and trunk.  The only
>>>> difference is that this module has been changed from dmake to gbuild in
>>>> trunk.
>>>>
>>>> The way that java detection works is that we scan the possible java
>>>> locations, and for each we run
>>>>   [path to javaa]/java[.exe] -classpath C:\\Program\ Files\\OpenOffice\ 
>>>> 4\\program JREProperties
>>>> which is supposed to output a bunch of data about that version of java,
>>>> which we read and parse.  If that fails, then we decide that version of
>>>> java is invalid or broken.
>>>>
>>>> When I build AOO418 with Java 8 and it tries to detect Java 7, I see
>>>> this stack trace sent to stderr:
>>>>
>>>> java.lang.UnsupportedClassVersionError: JREProperties : Unsupported 
>>>> major.minor version 52.0
>>>> at java.lang.ClassLoader.defineClass1(Native Method)
>>>> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
>>>> at 
>>>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>>>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>>>> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>>>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>>>> at 
>>>> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
>>>> Exception in thread "main"
>>>>
>>>> The problem is that the JREProperties was compiled with Java 8, which
>>>> Java 7 can't use:
>>>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
>>>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: 
>>>> compiled Java class data, version 52.0 (Java 1.8)
>>>>
>>>> If I build trunk with Java 8, I see:
>>>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
>>>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: 
>>>> compiled Java class data, version 51.0 (Java 1.7)
>>>> That's why we don't see this issue with trunk
>>>>
>>>> It is possible to use a new java compiler to build for older versions of
>>>> java using the --target option, but I don't see any sign that we are
>>>> doing so.
>>>>
>>>> Unfortunately the build is too silent for me to see what is actually
>>>> happening during the build.  My suspicion is that somehow the trunk
>>>> build is somehow using Java 7 to build.
>>> I finally figured out the difference.  The 4.1.x build uses the selected
>>> javac to build the .class file, whereas trunk and 42X use ant, and
>>> solenv/ant/aoo-ant.xml (new to trunk ant 42X) says:
>>> 
>>>
>>>> I see two paths forward.  The first is to build with the oldest version
>>>> of java that one might want to use, which is the status quo.  The second
>>>> is to somehow pass the --target option to specify an older java version
>>>> for compatibility.
>>> We could also cherry-pick the jvmfwk conversion to gbuild and the other
>>> changes for ant.
>> Even simpler, there is a JAVAFLAGS variable used by the dmake build.
>> Configure sets it:
>> JAVAFLAGS="-source 1.5 -target 1.5"
>> for Eclipse Java Compiler, but otherwise leaves it unset.
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: java detection

[Don Lewis]

On 25 Sep, Don Lewis wrote:
> On 24 Sep, Don Lewis wrote:
>> I've been looking into the problem where AOO418 can't detect older
>> versions of java when it is built with a new version of java.  This is a
>> definite puzzle because the detection is done by the jvmfwk module, and
>> the code in that module is identical between AOO418 and trunk.  The only
>> difference is that this module has been changed from dmake to gbuild in
>> trunk.
>> 
>> The way that java detection works is that we scan the possible java
>> locations, and for each we run
>>   [path to javaa]/java[.exe] -classpath C:\\Program\ Files\\OpenOffice\ 
>> 4\\program JREProperties
>> which is supposed to output a bunch of data about that version of java,
>> which we read and parse.  If that fails, then we decide that version of
>> java is invalid or broken.
>> 
>> When I build AOO418 with Java 8 and it tries to detect Java 7, I see
>> this stack trace sent to stderr:
>> 
>> java.lang.UnsupportedClassVersionError: JREProperties : Unsupported 
>> major.minor version 52.0
>> at java.lang.ClassLoader.defineClass1(Native Method)
>> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
>> at 
>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
>> at 
>> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
>> Exception in thread "main"
>> 
>> The problem is that the JREProperties was compiled with Java 8, which
>> Java 7 can't use:
>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: compiled 
>> Java class data, version 52.0 (Java 1.8)
>> 
>> If I build trunk with Java 8, I see:
>> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
>> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: compiled 
>> Java class data, version 51.0 (Java 1.7)
>> That's why we don't see this issue with trunk
>> 
>> It is possible to use a new java compiler to build for older versions of
>> java using the --target option, but I don't see any sign that we are
>> doing so.
>> 
>> Unfortunately the build is too silent for me to see what is actually
>> happening during the build.  My suspicion is that somehow the trunk
>> build is somehow using Java 7 to build.
> 
> I finally figured out the difference.  The 4.1.x build uses the selected
> javac to build the .class file, whereas trunk and 42X use ant, and
> solenv/ant/aoo-ant.xml (new to trunk ant 42X) says:
> 
> 
>> I see two paths forward.  The first is to build with the oldest version
>> of java that one might want to use, which is the status quo.  The second
>> is to somehow pass the --target option to specify an older java version
>> for compatibility.
> 
> We could also cherry-pick the jvmfwk conversion to gbuild and the other
> changes for ant.

Even simpler, there is a JAVAFLAGS variable used by the dmake build.
Configure sets it:
JAVAFLAGS="-source 1.5 -target 1.5"
for Eclipse Java Compiler, but otherwise leaves it unset.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: java detection

[Don Lewis]

On 24 Sep, Don Lewis wrote:
> I've been looking into the problem where AOO418 can't detect older
> versions of java when it is built with a new version of java.  This is a
> definite puzzle because the detection is done by the jvmfwk module, and
> the code in that module is identical between AOO418 and trunk.  The only
> difference is that this module has been changed from dmake to gbuild in
> trunk.
> 
> The way that java detection works is that we scan the possible java
> locations, and for each we run
>   [path to javaa]/java[.exe] -classpath C:\\Program\ Files\\OpenOffice\ 
> 4\\program JREProperties
> which is supposed to output a bunch of data about that version of java,
> which we read and parse.  If that fails, then we decide that version of
> java is invalid or broken.
> 
> When I build AOO418 with Java 8 and it tries to detect Java 7, I see
> this stack trace sent to stderr:
> 
> java.lang.UnsupportedClassVersionError: JREProperties : Unsupported 
> major.minor version 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at 
> sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
> Exception in thread "main"
> 
> The problem is that the JREProperties was compiled with Java 8, which
> Java 7 can't use:
> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: compiled 
> Java class data, version 52.0 (Java 1.8)
> 
> If I build trunk with Java 8, I see:
> $ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
> /cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: compiled 
> Java class data, version 51.0 (Java 1.7)
> That's why we don't see this issue with trunk
> 
> It is possible to use a new java compiler to build for older versions of
> java using the --target option, but I don't see any sign that we are
> doing so.
> 
> Unfortunately the build is too silent for me to see what is actually
> happening during the build.  My suspicion is that somehow the trunk
> build is somehow using Java 7 to build.

I finally figured out the difference.  The 4.1.x build uses the selected
javac to build the .class file, whereas trunk and 42X use ant, and
solenv/ant/aoo-ant.xml (new to trunk ant 42X) says:


> I see two paths forward.  The first is to build with the oldest version
> of java that one might want to use, which is the status quo.  The second
> is to somehow pass the --target option to specify an older java version
> for compatibility.

We could also cherry-pick the jvmfwk conversion to gbuild and the other
changes for ant.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418 cherry picks

[Don Lewis]

On 24 Sep, Matthias Seidel wrote:
> Great!
> 
> We should also cherry-pick Don's Python update:
> 
> https://github.com/apache/openoffice/commit/26aca12f509e5c739c98db9ce5641a2c5feecea7
> 
> And update LICENSE:
> 
> https://github.com/apache/openoffice/commit/1dedf1ecff4aeffe2f7c7612cbf893530465764e

Now that the big merge is out of the way, I've started working on
testing this for a pull request.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418 cherry picks

[Don Lewis]

On 24 Sep, Jim Jagielski wrote:
> Well, gotten further but now there are packaging issues. Something with the 
> new apr/apr-util/serf stuff is getting hosed... looking into it:
> 
> ERROR: The following files could not be found: 
> ERROR: File not found: libapr-1.0.5.2.dylib
> ERROR: File not found: libaprutil-1.0.5.4.dylib
> ERROR: File not found: libserf-1.0.0.0.dylib
> ... cleaning the output tree ...
> ... removing directory 
> /var/folders/_p/nx0kp5h157197n6ssf35ft7hgn/T/ooopackaging/i_446601600974718

I don't think there were any changes to serf.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

java detection

[Don Lewis]

I've been looking into the problem where AOO418 can't detect older
versions of java when it is built with a new version of java.  This is a
definite puzzle because the detection is done by the jvmfwk module, and
the code in that module is identical between AOO418 and trunk.  The only
difference is that this module has been changed from dmake to gbuild in
trunk.

The way that java detection works is that we scan the possible java
locations, and for each we run
  [path to javaa]/java[.exe] -classpath C:\\Program\ Files\\OpenOffice\ 
4\\program JREProperties
which is supposed to output a bunch of data about that version of java,
which we read and parse.  If that fails, then we decide that version of
java is invalid or broken.

When I build AOO418 with Java 8 and it tries to detect Java 7, I see
this stack trace sent to stderr:

java.lang.UnsupportedClassVersionError: JREProperties : Unsupported major.minor 
version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
Exception in thread "main"

The problem is that the JREProperties was compiled with Java 8, which
Java 7 can't use:
$ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
/cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: compiled 
Java class data, version 52.0 (Java 1.8)

If I build trunk with Java 8, I see:
$ file /cygdrive/c/Program\ Files/OpenOffice\ 4/program/JREProperties.class
/cygdrive/c/Program Files/OpenOffice 4/program/JREProperties.class: compiled 
Java class data, version 51.0 (Java 1.7)
That's why we don't see this issue with trunk

It is possible to use a new java compiler to build for older versions of
java using the --target option, but I don't see any sign that we are
doing so.

Unfortunately the build is too silent for me to see what is actually
happening during the build.  My suspicion is that somehow the trunk
build is somehow using Java 7 to build.

I see two paths forward.  The first is to build with the oldest version
of java that one might want to use, which is the status quo.  The second
is to somehow pass the --target option to specify an older java version
for compatibility.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418 cherry picks

[Don Lewis]

On 22 Sep, Jim Jagielski wrote:
> Just a FYI that HEAD of AOO418 builds on macOS with no issues so far...

https://github.com/apache/openoffice/pull/94 has some macOS-specific
changes from AOO42X.




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Minimum MacOS Version for trunk and 4.2.0 builds

[Don Lewis]

On 20 Sep, Peter Kovacs wrote:
> 
> Am 20.09.20 um 20:16 schrieb Dave Fisher:
>>> On Sep 20, 2020, at 9:40 AM, Marcus  wrote:
>>>
>>> Am 19.09.20 um 12:36 schrieb Peter Kovacs:
 Keep in mind that C++ Standard has changed a lot in reasoned years,
 and at least I would like to go with the new standard. If we stick
 to the old code for long time it will make maintenance or
development more difficuilt. yes, that's why I wrote:
>>>
>>> ... keeping the baseline for every OS as long as (technically)
>>>possible ... As long as a compiler exists on that platform that
>>>compiles the older language standard we should not upgrade.
>>
>> I started this thread to discuss build tools and to consider what to
>> do when it becomes difficult to build and have the result work on a
>> minimum platform.
>>
>> My original suggestion is that:
>>
>> (1) 4.1.X always keeps the current OS minimums.
> IMHO we should retire 4.1.X as soon as we have stabilized 4.2.X
>> (2) Should 4.2 branch also keep the current OS minimums or consider
>> more recent OSs as minimums? Is there anything currently on that
>> branch that is a concern?
>>
>> (3) Should we consider more recent OS minimums for trunk which may
>> become 4.5 or 5.0?
> 
> I think we should adjust 4.2.0 but keep trunk the same for now. After 
> release we will have some more fixes to do.
> 
>>
>> What should drive the choice for a more recent minimums? Unavoidable
>> incompatibilities.
> 
> 1) I think we have to work between OSes our user use and the 
> Requirements our dependencies have.
> 
> 2) We have difficulties to update some dependencies since they made a 
> change to c++11 or later standard. In a serious way it would mean we 
> would have to maintain those dependencies or we find a way to backport 
> some C++ features. (i do not have a list.)

The only requirement for C++11 that I've run into is with very recent
versions of vigra.  That's not a depenency that we've ever tried to
upgrade.  I only discovered the issue because of the FreeBSD port, which
was using the system vigra package.  When vigra was updated on FreeBSD,
the port stopped building in C++98 mode, so I switched the port to the
bundled vigra.

The biggest problem I've run into is the lack of C99 support by the old
version of Visual C++ that we use on Windows.  Recent versions of nss
use C99 pretty heavily.  Getting C99 support requires a fairly recent
version of Visual C++.  Microsoft intends that the compiler be used
primarily for compiling C++, so they let the C support lag pretty far
behind.


> 3) Then the SDKs are moved out of maintenance. On Windows our SDK used 
> in the 4.1.X is already not available. On Mac we have a useable SDK 
> 10.10 that let us keep the Lion minimum OS, but the question is how 
> long. Changeing SDKs seems to be a lot of work. We should consider to 
> move away from the verge of availability.
> 
>> Has anyone studied modern Java JDKs and if there is an impact on
>> OpenOffice?
> 
> Mechtilde reported that our build fails on recent Debian due to Java 11.
> 
> 
> My suggestion is:
> 
> Linux: Move to CentOs 7 (As we have already decided)
> 
> MacOSX: Move to 10.10 (And see how much we can move up on the SDK side.
> 
> Windows: Keep WinXP and Move up SDKs as much as possible. (I think 
> latest SDK still supports WinXP target, but I am not sure.)
> 
> 
> All the best
> 
> Peter
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Minimum MacOS Version for trunk and 4.2.0 builds

[Don Lewis]

On 20 Sep, Dave Fisher wrote:
> 
> 
>> On Sep 20, 2020, at 9:40 AM, Marcus  wrote:
>> 
>> Am 19.09.20 um 12:36 schrieb Peter Kovacs:
>>> Keep in mind that C++ Standard has changed a lot in reasoned years,
>>> and at least I would like to go with the new standard. If we stick
>>> to the old code for long time it will make maintenance or
>>> development more difficuilt.
>> 
>> yes, that's why I wrote:
>> 
>> ... keeping the baseline for every OS as long as (technically)
>> possible ...
> 
> As long as a compiler exists on that platform that compiles the older
> language standard we should not upgrade.
> 
> I started this thread to discuss build tools and to consider what to
> do when it becomes difficult to build and have the result work on a
> minimum platform.
> 
> My original suggestion is that:
> 
> (1) 4.1.X always keeps the current OS minimums.
> 
> (2) Should 4.2 branch also keep the current OS minimums or consider
> more recent OSs as minimums? Is there anything currently on that
> branch that is a concern?

In 4.2 and trunk we switched to supporting a newer version of gstreamer,
which is only available in CentOS 7 and above I believe.

If you want to have a working gstreamer, which is optional, 4.1.x is
stuck at CentOS 5 and 6.  CentOS 7 does not have a package for the old
gstreamer.

I don't know the situation for the other Linux distros.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [GitHub] [openoffice] DonLewisFreeBSD opened a new pull request #94: Bundle418

[Don Lewis]

After dodging a local wildfire and potential evacuation, excessive heat
warnings and requests by the power company to conserve power, possible
rolling blackouts due to power shortages, high wind warnings with a two
day Public Safety Power Shutoff to avoid power-line caused fires, smoke
plumes from other fires within a couple of hundred miles that filled the
air with hazardous amounts of smoke, and then finally catching up on
some of my backlog ... I finally have the bundled software update for
AOO418 ready.

On 16 Sep, GitBox wrote:
> 
> DonLewisFreeBSD opened a new pull request #94:
> URL: https://github.com/apache/openoffice/pull/94
> 
> 
>Cherry pick bundled software upgrades from AOO42X:
>
>Upgrade ext_libraries:
>apr
>apr-util
>hunspell-1.3.3
>ratscan
>
>Upgrade main modules:
>apache-commons
>beanshell
>libxml2
>libxslt
>more_fonts
>nss
>python
>redland
>
>external_deps.lst cleanups
> 
> 
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
> 
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418 cherry picks

[Don Lewis]

On  4 Sep, Matthias Seidel wrote:
> Hi Jim, Don,
> 
> Am 28.08.20 um 15:17 schrieb Jim Jagielski:
>> Let's commit and work after pushed.
> 
> We should try
> 
> https://bz.apache.org/ooo/show_bug.cgi?id=127887
> 
> again for 4.1.8.

I've included it in a large bundle of cherry-picks that I've been
testing.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

libxslt upgrade breaks CentOS 5 build

[Don Lewis]

I've been looking at upgrading a bunch of our bundled dependencies, and
it looks like upgrading libxslt (or maybe libxml2) breaks the build on
CentOS 5.

The writerfilter module uses xsltproc to generate the header
resources.hxx, and in some cases it contains invalid C cod such as:
return (getU32(744))>>;
whereas it should be:
return (getU32(744));

The shift fragment of this expression comes from this xsl template:
...

   
  

;
If there is a nonzero shift, the it should output "foo>>shift;", and if
the shift amount is zero, then it should just output "foo;".

In the normal case, the input data looks like:
  

  0
  

  

  
for a shift amount of zero.  One example of the broken case it is:
  

  
  

  

  
so the value is missing (the tag is self-closing in this case),
so presumably the if condition in the template is 'if test=">0"'. So
this input is looking pretty questionable.

The mystery is why this behaves differently on CentOS 5 vs. everywhere
else.  Only the resources.hxx header generated by CentOS 5 is broken.

One thing I noticed is that my CentOS 5 machine has system libxml and
libxslt libraries installed and they have the same library version
numbers as the ones we build.  My CentOS 6 machine does not.  The system
xsltproc generates a valid resources.hxx header.  One thought I had was
that the xsltproc that we build might be picking up the system
librariese and there was some subtle incompatiblity, but that does not
appear to be the case.  My other thought was some sort of compiler bug
triggered by the new code, but building the libxml2 and libxslt modules
with -O0 optimization did not change anything.

Probably the best fix is to modify the template to check for blank shift
values, but the mystery remains.

--- a/main/writerfilter/source/doctok/resources.xsl
+++ b/main/writerfilter/source/doctok/resources.xsl
@@ -576,7 +576,7 @@ class 
   
 
 )
-
+

   
 




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: installing git on centos 5.5

[Don Lewis]

On 30 Aug, Carl Marcum wrote:
> Hi Don,
> 
> On 8/29/20 8:02 PM, Don Lewis wrote:
>> On 29 Aug, Don Lewis wrote:
>>> On 29 Aug, Don Lewis wrote:
>>>> On 23 Aug, Carl Marcum wrote:
>>>>> I'm setting up a new CentOS 5.5 VM that I can build 4.1.x series on.
>>>>>
>>>>> First hurdle was figuring out out how to point to the vault.centos.org
>>>>> archived rpms.
>>>>> Unfortunately no git was available then.
>>>> I've managed to resurrect my CentOS 5 VM.
>>>>
>>>> git builds from source out of the box, but as I suspected, the system
>>>> openssl is too old to talk to github.
>>>>
>>>> Download and unpack openssl-1.0.2u.  Build and install according to the
>>>> instructions.  At the configure step:
>>>>./config --shared
>>>>
>>>> Download and unpack curl-7.71.1. Build and install.  At the configure
>>>> step:
>>>>LDFLAGS=-Wl,-R/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl 
>>>> --disable-ldap
>>>>
>>>> Download and unpack git-2.28.0.  At the configure step:
>>>>./configure --with-openssl=/usr/local/ssl
>>> Not quite ... it was only working for me because I had set
>>> $LD_LIBRARY_PATH. Instead do this:
>>> LDFLAGS=-Wl,-R/usr/local/lib ./configure --with-openssl=/usr/local/ssl
>>> 
>>>> At the build step:
>>>>make CURL_DIR=/usr/local
>> Be preparied to download the anything missing from ext_sources elsewhere
>> and copy the files to the CentOS machine manually.  Because of the old
>> system OpenSSL, bootstrap can't speak https to much of anything.  Same
>> fro trying to use wget.
> 
> Thank you for the great replies.
> 
> I'm currently trying to build it on CentOS 6 since it has support until 
> November this year.
> The build has stopped a few times but I think I'm getting close.
> 
> Then I'll go back and try 5.

I am able to build AOO418 on 32-bit 5.




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: installing git on centos 5.5

[Don Lewis]

On 29 Aug, Don Lewis wrote:
> On 29 Aug, Don Lewis wrote:
>> On 23 Aug, Carl Marcum wrote:
>>> I'm setting up a new CentOS 5.5 VM that I can build 4.1.x series on.
>>> 
>>> First hurdle was figuring out out how to point to the vault.centos.org 
>>> archived rpms.
>>> Unfortunately no git was available then.
>> 
>> I've managed to resurrect my CentOS 5 VM.
>> 
>> git builds from source out of the box, but as I suspected, the system
>> openssl is too old to talk to github.
>> 
>> Download and unpack openssl-1.0.2u.  Build and install according to the
>> instructions.  At the configure step:
>>   ./config --shared
>> 
>> Download and unpack curl-7.71.1. Build and install.  At the configure
>> step:
>>   LDFLAGS=-Wl,-R/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl 
>> --disable-ldap
>> 
>> Download and unpack git-2.28.0.  At the configure step:
>>   ./configure --with-openssl=/usr/local/ssl
> 
> Not quite ... it was only working for me because I had set
> $LD_LIBRARY_PATH. Instead do this:
>LDFLAGS=-Wl,-R/usr/local/lib ./configure --with-openssl=/usr/local/ssl
>
>> At the build step:
>>   make CURL_DIR=/usr/local

Be preparied to download the anything missing from ext_sources elsewhere
and copy the files to the CentOS machine manually.  Because of the old
system OpenSSL, bootstrap can't speak https to much of anything.  Same
fro trying to use wget.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: installing git on centos 5.5

[Don Lewis]

On 29 Aug, Don Lewis wrote:
> On 23 Aug, Carl Marcum wrote:
>> I'm setting up a new CentOS 5.5 VM that I can build 4.1.x series on.
>> 
>> First hurdle was figuring out out how to point to the vault.centos.org 
>> archived rpms.
>> Unfortunately no git was available then.
> 
> I've managed to resurrect my CentOS 5 VM.
> 
> git builds from source out of the box, but as I suspected, the system
> openssl is too old to talk to github.
> 
> Download and unpack openssl-1.0.2u.  Build and install according to the
> instructions.  At the configure step:
>   ./config --shared
> 
> Download and unpack curl-7.71.1. Build and install.  At the configure
> step:
>   LDFLAGS=-Wl,-R/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl 
> --disable-ldap
> 
> Download and unpack git-2.28.0.  At the configure step:
>   ./configure --with-openssl=/usr/local/ssl

Not quite ... it was only working for me because I had set
$LD_LIBRARY_PATH. Instead do this:
   LDFLAGS=-Wl,-R/usr/local/lib ./configure --with-openssl=/usr/local/ssl
   
> At the build step:
>   make CURL_DIR=/usr/local


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: installing git on centos 5.5

[Don Lewis]

On 29 Aug, Don Lewis wrote:
> On 23 Aug, Carl Marcum wrote:
>> I'm setting up a new CentOS 5.5 VM that I can build 4.1.x series on.
>> 
>> First hurdle was figuring out out how to point to the vault.centos.org 
>> archived rpms.
>> Unfortunately no git was available then.
> 
> I've managed to resurrect my CentOS 5 VM.
> 
> git builds from source out of the box, but as I suspected, the system
> openssl is too old to talk to github.
> 
> Download and unpack openssl-1.0.2u.  Build and install according to the
> instructions.  At the configure step:
>   ./config --shared
> 
> Download and unpack curl-7.71.1. Build and install.  At the configure
> step:
>   LDFLAGS=-Wl,-R/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl 
> --disable-ldap
> 
> Download and unpack git-2.28.0.  At the configure step:
>   ./configure --with-openssl=/usr/local/ssl
> At the build step:
>   make CURL_DIR=/usr/local

BTW, I have only tested https URLs.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: installing git on centos 5.5

[Don Lewis]

On 23 Aug, Carl Marcum wrote:
> I'm setting up a new CentOS 5.5 VM that I can build 4.1.x series on.
> 
> First hurdle was figuring out out how to point to the vault.centos.org 
> archived rpms.
> Unfortunately no git was available then.

I've managed to resurrect my CentOS 5 VM.

git builds from source out of the box, but as I suspected, the system
openssl is too old to talk to github.

Download and unpack openssl-1.0.2u.  Build and install according to the
instructions.  At the configure step:
  ./config --shared

Download and unpack curl-7.71.1. Build and install.  At the configure
step:
  LDFLAGS=-Wl,-R/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl 
--disable-ldap

Download and unpack git-2.28.0.  At the configure step:
  ./configure --with-openssl=/usr/local/ssl
At the build step:
  make CURL_DIR=/usr/local


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO418 cherry picks

[Don Lewis]

On 27 Aug, Matthias Seidel wrote:
> Am 27.08.20 um 19:32 schrieb Matthias Seidel:
>>
>> Hi Don,
>>
>> Am 24.08.20 um 04:04 schrieb Don Lewis:
>>> I've got a bunch of cherry picks that I'm planning to merge into AOO418.
>>> There are two categories:
>>>   * Fixes from the FreeBSD port that have been upstreamed to the trunk
>>> and AOO42X branches, but I'm still carrying around in the FreeBSD
>>> port of 4.1.7.
>>>
>>>   * Updates of a bunch of the bundled dependencies.  These have been
>>> updated in AOO42X and trunk for a while, but haven't been merged to
>>> AOO418.  The FreeBSD port mostly usees the system versions of these.
>>>
>>> I'd like to revisit:
>>>
>>>   commit 7a3beb322b74df1b6c96e03605837df34781c68f
>>>   Author: Matthias Seidel 
>>>   Date:   Thu Oct 11 16:53:51 2018 +
>>>   
>>>   Rollback to Rev. 1843088 due to build errors.
>>>   
>>>   git-svn-id: 
>>> https://svn.apache.org/repos/asf/openoffice/branches/AOO416@18438571 
>>> 13f79535-47bb-0310-9956-ffa450edef68
>>>
>>> I'm still using the patch for the FreeBSD port.  Without it, a build
>>> with --enable-odk will fail with Java 8 or newer.  I don't see how it
>>> would break the build since the changes are just to structured comments
>>> that are parsed to generate the documentation in the ODK.  When this was
>>> backed out, I thought the reason was that building with a newer version
>>> of the JDK would prevent runtime detection of older versions of the JDK.
>>> So far asa I know, that's not a problem with AOO42X and trunk, which
>>> have the changes.
>>
>> If I remember it right the Rollback included:
>>
>>  - Issue 127887 - update bundled redland/raptor/rasqal
>>  - Issue 127875 - fix a loop that visits all objects on a page so that
>> all objects get visited
>>  - Issue 127874 - fix bad potential invalid subscript bug when using
>> Microsoft Uniscribe text layout API
>>
>> We should commit all of the above again, one after the other.
>>
> Correcting myself: I had re-committed Issue 127874 and Issue 127875 to
> 4.1.6 after the Rollback.
> 
> So Issue 127887 could now be committed to 4.1.8.
> We should discuss the change in configure.in regarding MacOS with Jim.

I'm working on a fairly large update to the bundled software.  I should
be able to create a pull request in a day or so.  127887 will be
included.  I'll test it on Linux and Windows.  I'll take a stab at the
MacOS bits, but won't be able to test it.

> Regards,
> 
>    Matthias
> 
>> "Issue 127876 - unbreak ODK build with Java 8" should be double
>> checked because of the known issue with Java 7 JRE.

Since 127876 only changes comments in our Java code, it should not
affect detection.  Without this change, is the Java 7 JRE detected if we
build with Java 8?


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

[Don Lewis]

On 27 Aug, Matthias Seidel wrote:
> Hi Don,
> 
> Am 26.08.20 um 03:55 schrieb Don Lewis:
>> On 25 Aug, Don Lewis wrote:
>>> On 25 Aug, Pedro Lino wrote:
>>>>> On 08/25/2020 8:35 PM Don Lewis  wrote:
>>>>> Try deleting /opt/openoffice4/program/libgcc_s.so.1
>>>>> For some reason that bogus file is getting packaged by your build.
>>>> Yep. That fixed it. It doesn't make any sense to me that an extra file
>>>> prevents the program from working... Maybe this is part of some
>>>> forgotten/abandoned code?
>>> That file is in the shared library search path.  When you try to start a
>>> program, it is being found instead of the correct shared library file
>>> under /lib, causing the runtime linker to blow a gasket.
>>>
>>>> But the file is checked during compiling. If the file is not present,
>>>> building "postprocess" will fail...
>>>>
>>>> I will try building with --with-system-stdlibs
>>>>
>>>> Thank you for the tips and fixes!
>> I dug into this a bit more.  It turns out that the bogus copy of
>> libgcc_s.so.1 is a linker script and not a shared library.   Linker 
>> scripts are a failrly new thing, which is why we haven't run into this
>> before.  The build code that is grabbing this file was removed from
>> trunk and AOO42X a few years ago, which is why you didn't see the
>> problem with those versions.  I've cherry-picked the fix and will push
>> it to AOO418 after I've had a chance to test it.
> 
> Great!
> 
> Then we can set this issue (i104495 - libstdc++ removal) to
> resolved/fixed now?

I guess so, though I haven't tested the KDE bits.
 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

[Don Lewis]

On 25 Aug, Don Lewis wrote:
> On 25 Aug, Don Lewis wrote:
>> On 25 Aug, Pedro Lino wrote:
>>> 
>>>> On 08/25/2020 8:35 PM Don Lewis  wrote:
>>> 
>>>> Try deleting /opt/openoffice4/program/libgcc_s.so.1
>>>> For some reason that bogus file is getting packaged by your build.
>>> 
>>> Yep. That fixed it. It doesn't make any sense to me that an extra file
>>> prevents the program from working... Maybe this is part of some
>>> forgotten/abandoned code?
>> 
>> That file is in the shared library search path.  When you try to start a
>> program, it is being found instead of the correct shared library file
>> under /lib, causing the runtime linker to blow a gasket.
>> 
>>> But the file is checked during compiling. If the file is not present,
>>> building "postprocess" will fail...
>>> 
>>> I will try building with --with-system-stdlibs
>>> 
>>> Thank you for the tips and fixes!
> 
> I dug into this a bit more.  It turns out that the bogus copy of
> libgcc_s.so.1 is a linker script and not a shared library.   Linker 
> scripts are a failrly new thing, which is why we haven't run into this
> before.  The build code that is grabbing this file was removed from
> trunk and AOO42X a few years ago, which is why you didn't see the
> problem with those versions.  I've cherry-picked the fix and will push
> it to AOO418 after I've had a chance to test it.

I just updated AOO418 with the fix.  You should be able to successfully
build and run --without-system-stdlibs.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

[Don Lewis]

On 25 Aug, Don Lewis wrote:
> On 25 Aug, Pedro Lino wrote:
>> 
>>> On 08/25/2020 8:35 PM Don Lewis  wrote:
>> 
>>> Try deleting /opt/openoffice4/program/libgcc_s.so.1
>>> For some reason that bogus file is getting packaged by your build.
>> 
>> Yep. That fixed it. It doesn't make any sense to me that an extra file
>> prevents the program from working... Maybe this is part of some
>> forgotten/abandoned code?
> 
> That file is in the shared library search path.  When you try to start a
> program, it is being found instead of the correct shared library file
> under /lib, causing the runtime linker to blow a gasket.
> 
>> But the file is checked during compiling. If the file is not present,
>> building "postprocess" will fail...
>> 
>> I will try building with --with-system-stdlibs
>> 
>> Thank you for the tips and fixes!

I dug into this a bit more.  It turns out that the bogus copy of
libgcc_s.so.1 is a linker script and not a shared library.   Linker 
scripts are a failrly new thing, which is why we haven't run into this
before.  The build code that is grabbing this file was removed from
trunk and AOO42X a few years ago, which is why you didn't see the
problem with those versions.  I've cherry-picked the fix and will push
it to AOO418 after I've had a chance to test it.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

[Don Lewis]

On 25 Aug, Pedro Lino wrote:
> 
>> On 08/25/2020 8:35 PM Don Lewis  wrote:
> 
>> Try deleting /opt/openoffice4/program/libgcc_s.so.1
>> For some reason that bogus file is getting packaged by your build.
> 
> Yep. That fixed it. It doesn't make any sense to me that an extra file
> prevents the program from working... Maybe this is part of some
> forgotten/abandoned code?

That file is in the shared library search path.  When you try to start a
program, it is being found instead of the correct shared library file
under /lib, causing the runtime linker to blow a gasket.

> But the file is checked during compiling. If the file is not present,
> building "postprocess" will fail...
> 
> I will try building with --with-system-stdlibs
> 
> Thank you for the tips and fixes!
> 
> Best,
> Pedro
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

[Don Lewis]

On 25 Aug, Pedro Lino wrote:
> Hi Matthias
> 
>> On 08/25/2020 8:07 PM Matthias Seidel  wrote:
> 
>> If you start AOO in a shell with "soffice", does that give some information?
> 
> Didn't think about that :)
> 
> /opt/openoffice4/program/javaldx: error while loading shared libraries: 
> /opt/openoffice4/program/libgcc_s.so.1: invalid ELF header
> /opt/openoffice4/program/soffice.bin: error while loading shared libraries: 
> /opt/openoffice4/program/libgcc_s.so.1: invalid ELF header

I configure with --with-system-stdlibs

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

[Don Lewis]

On 25 Aug, Pedro Lino wrote:
> Hi Matthias
> 
>> On 08/25/2020 8:07 PM Matthias Seidel  wrote:
> 
>> If you start AOO in a shell with "soffice", does that give some information?
> 
> Didn't think about that :)
> 
> /opt/openoffice4/program/javaldx: error while loading shared libraries: 
> /opt/openoffice4/program/libgcc_s.so.1: invalid ELF header
> /opt/openoffice4/program/soffice.bin: error while loading shared libraries: 
> /opt/openoffice4/program/libgcc_s.so.1: invalid ELF header

Try deleting /opt/openoffice4/program/libgcc_s.so.1
For some reason that bogus file is getting packaged by your build.  I'm
not seeing that happen here:
$ ls /opt/openoffice4/program/libg*
/opt/openoffice4/program/libgcc3_uno.so
/opt/openoffice4/program/libguesslang.so


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

[Don Lewis]

On 25 Aug, Matthias Seidel wrote:
> Hi Pedro,
> 
> Am 25.08.20 um 20:11 schrieb Pedro Lino:
>> Hi Don
>>
>>> On 08/25/2020 10:59 AM Don Lewis  wrote:
>>> With the latest batch of cherry-picks that I just pushed to AOO418 and
>>> using OpenJDK 8, I was able to build AOO418 on Ubuntu 18.
>> After updating with your latest changes and hacking a bit with the libgcc 
>> file mentioned in the subject, compiling ended with success. However after 
>> installing (without errors) the program doesn't run...
> 
> If you start AOO in a shell with "soffice", does that give some information?

For me, it goes through the registration process and then I can create
and save a writer document.  If I exit, I can reopen the document from
the command line.  Looks like it works.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Spurious file libgcc_s.so.1 during Linux build [Was: OpenSSL versions]

[Don Lewis]

On 25 Aug, Pedro Lino wrote:
> Hi Don
> 
>> On 08/25/2020 10:59 AM Don Lewis  wrote:
> 
>> With the latest batch of cherry-picks that I just pushed to AOO418
>> and using OpenJDK 8, I was able to build AOO418 on Ubuntu 18.
> 
> After updating with your latest changes and hacking a bit with the
> libgcc file mentioned in the subject, compiling ended with success.
> However after installing (without errors) the program doesn't run...
> 
> Did you install (or execute the binaries)? If they work can you share
> the tar.gz file?

I haven't had a chance to install it.  Once it built, I declared victory
and went to sleep.

I didn't run into the libgcc_s.so.1 problem.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org