Re: LLVM exit code 139 building git master on Xubuntu 22.04

[David Gerard]

On Thu, 19 Oct 2023 at 07:26, Stephan Bergmann  wrote:
> On 10/18/23 23:08, David Gerard wrote:

> > I just tried again from a completely fresh git clone, and it's still
> > happening. Any ideas? Is there anything in the new C++20 conf that's
> > too new for llvm 14.0.0 Ubuntu version?

> Smells like a bug in that particular version of Clang.  I'd follow the
> printed instructions to report it, either directly upstream at LLVM or
> (presumably better) at Ubuntu first.


So rather than file a bug and wait, I first tried a newer version of
clang, and clang-15 worked. Hooray!

Here's what I did:

# Become root

sudo -s

# install clang-15

apt remove llvm-14 clang-14 libclang-cpp14 libclang1-14
apt autoremove
apt install clang-15 llvm-15 libclang-cpp15 libclang1-15

# put its binaries in the path - no, there doesn't seem to be a more elegant way

cd /usr/lib/llvm-15/bin
for f in *; do rm -f /usr/bin/$f; ln -s ../lib/llvm-15/bin/$f /usr/bin/$f; done

and then get out of root and ./autogen.sh


- d.

Re: LLVM exit code 139 building git master on Xubuntu 22.04

[David Gerard]

On Tue, 17 Oct 2023 at 21:33, David Gerard  wrote:

> I pulled from git master today to build LO and got LLVM exit code 139
> - an error code I can't find the meaning of, but it's apparently an
> internal error.

I just tried again from a completely fresh git clone, and it's still
happening. Any ideas? Is there anything in the new C++20 conf that's
too new for llvm 14.0.0 Ubuntu version?


- d.

LLVM exit code 139 building git master on Xubuntu 22.04

[David Gerard]

I pulled from git master today to build LO and got LLVM exit code 139
- an error code I can't find the meaning of, but it's apparently an
internal error.

The build ends like this, even after a make clean (I've cut the stack dump):

...
[CXX] sal/osl/unx/tempfile.cxx
[CXX] sal/osl/unx/thread.cxx
[CXX] sal/osl/unx/time.cxx
[CXX] sal/osl/unx/uunxapi.cxx
[CXX] sal/osl/unx/system.cxx
PLEASE submit a bug report to
https://github.com/llvm/llvm-project/issues/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0.Program arguments: /usr/bin/c++ -DBOOST_ERROR_CODE_HEADER_ONLY
-DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DLINUX -DNDEBUG
-DOSL_DEBUG_LEVEL=0 -DUNIX -DUNX -DX86_64 -D_PTHREADS -D_REENTRANT
-DSAL_DLLIMPLEMENTATION -DRTL_OS=\"Linux\" -DRTL_ARCH=\"X86_64\"
-DSRCDIR=\"/home/fun/libreoffice\" -DCOND_LIB_SAL_TEXTENC
-DSYSTEM_ZLIB -DZLIB_CONST -fvisibility=hidden -Wall
-Wno-missing-braces -Wendif-labels -Wextra -Wundef -Wunreachable-code
-Wshadow -Wunused-macros -Wembedded-directive -finput-charset=UTF-8
-fmessage-length=0 -fno-common -pipe -fstack-protector-strong
-Wdeprecated-copy-dtor -Wimplicit-fallthrough
-Wunused-exception-parameter -Wrange-loop-analysis
-fvisibility-inlines-hidden -fPIC -Wshadow -Woverloaded-virtual
-std=c++20 -pthread -O2 -fexceptions -DLIBO_INTERNAL_ONLY -c
/home/fun/libreoffice/sal/osl/all/debugbase.cxx -o
/home/fun/libreoffice/workdir/CxxObject/sal/osl/all/debugbase.o -MMD
-MT /home/fun/libreoffice/workdir/CxxObject/sal/osl/all/debugbase.o
-MP -MF /home/fun/libreoffice/workdir/Dep/CxxObject/sal/osl/all/debugbase.d_
-I/home/fun/libreoffice/workdir/UnpackedTarball/dtoa/include/
-I/home/fun/libreoffice/workdir/UnpackedTarball/dragonbox/include/
-I/home/fun/libreoffice/include
-I/usr/lib/jvm/java-17-openjdk-amd64/include
-I/usr/lib/jvm/java-17-openjdk-amd64/include/linux
-I/home/fun/libreoffice/config_host -I/home/fun/libreoffice/sal/inc
-fcolor-diagnostics
1./home/fun/libreoffice/sal/osl/all/debugbase.cxx:52:8: current
parser token ';'
2./home/fun/libreoffice/sal/osl/all/debugbase.cxx:30:1: parsing
namespace '(anonymous)'
3./home/fun/libreoffice/sal/osl/all/debugbase.cxx:33:1: parsing
function body '(anonymous namespace)::StaticDebugBaseAddressFilter'
4./home/fun/libreoffice/sal/osl/all/debugbase.cxx:33:1: in
compound statement ('{}')
Stack dump without symbol names (ensure you have llvm-symbolizer in
your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point
to it):

[...]

clang: error: clang frontend command failed with exit code 139 (use -v
to see invocation)
Ubuntu clang version 14.0.0-1ubuntu1.1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin


I don't see everyone else complaining about this, so I expect it's
something special in my setup. Does anyone have any idea?


- thanks, David.

Re: LO 24.2 C++20 baseline

[David Gerard]

On Sun, 24 Sept 2023 at 00:33, David Gerard  wrote:
> On Sun, 24 Sept 2023 at 00:20, David Gerard  wrote:

> > For gcc 12, as i understand it I'd have to try to bodge in the debs
> > from 22.10 (the current experimental version) or compile it from
> > source.

> sorry, I mean debs from 22.10 or later - 22.10 and 23.04 supply gcc12,
> 23.10 supplies gcc13, so I'm guessing 24.04 will supply gcc13 as well.


OK, never mind me! The following works:

sudo apt remove gcc# removes gcc-11, g++-11, build-essential
sudo apt install gcc-12 g++-12

So far it's compiling ...


- d.

Re: LO 24.2 C++20 baseline

[David Gerard]

On Sun, 24 Sept 2023 at 00:20, David Gerard  wrote:

> For gcc 12, as i understand it I'd have to try to bodge in the debs
> from 22.10 (the current experimental version) or compile it from
> source.

sorry, I mean debs from 22.10 or later - 22.10 and 23.04 supply gcc12,
23.10 supplies gcc13, so I'm guessing 24.04 will supply gcc13 as well.


- d.

Re: LO 24.2 C++20 baseline

[David Gerard]

> I just submitted
> 
> "Bump baseline to C++20" to master.  I will let it sit like that for a
> few more days, to see if anything breaks (Coverity? Linux distros'
> needs? etc.), before cleaning up now-unnecessary `#if __cplusplus <
> 202002L` etc., and before potentially unleashing the rewriting Clang
> plugin to mass-introduce uses of u""_ustr that I talked about
> yesterday at 
> 
"> If I Had C++20".

Unfortunately, this breaks the current Ubuntu LTS, 22.04 - LibreOffice
can't be compiled on it any more:

configure: error: GCC 11.4.0 is too old, must be at least GCC 12
Error running configure at /home/fun/libreoffice/autogen.sh line 321.
make: *** [Makefile:56: /home/fun/libreoffice/config_host.mk] Error 1

$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

For gcc 12, as i understand it I'd have to try to bodge in the debs
from 22.10 (the current experimental version) or compile it from
source.

The next Ubuntu LTS is 24.04.


- d.

Re: Build from master failing on Xubuntu 16.04: DesktopLOKTest::testRunMacro assertion failed

[David Gerard]

On 5 April 2017 at 22:42, Chris Sherlock  wrote:

> I guess in many ways he's our LibreOffice historian. I hope one day he comes 
> to a LibreOffice related conference, if only to say hello to the devs. I'm 
> sure he would love that and frankly I'd love to be a fly on the wall when he 
> meets Michael Meeks!


I'll have you know I Wikipedia entirely neutrally! And I'd probably
get him for an interview ...

(which I don't have time for any time soon :-)




- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build from master failing on Xubuntu 16.04: DesktopLOKTest::testRunMacro assertion failed

[David Gerard]

On 23 March 2017 at 17:33, David Gerard <dger...@gmail.com> wrote:
> On 23 March 2017 at 17:18, Thorsten Behrens <t...@libreoffice.org> wrote:
>> David Gerard wrote:

>>> Building from master on Lenovo X240 running Xubuntu 16.04 64-bit, it
>>> consistently fails with this:

>> Hmm - can you paste/mail us your configure line? I have a hunch why
>> that might fail...

> ./configure --with-gdrive-client-secret=[secret]
> --with-gdrive-client-id=[client-id] --prefix=/home/fun/bin/libreoffice
> --with-parallelism=1 --srcdir=/home/fun/libreoffice
> --enable-option-checking=fatal


Tried just now with latest master and it's compiling fine. I glanced
at the commits but couldn't work out what fixed it. But all is well
:-)


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build from master failing on Xubuntu 16.04: DesktopLOKTest::testRunMacro assertion failed

[David Gerard]

On 23 March 2017 at 17:18, Thorsten Behrens <t...@libreoffice.org> wrote:
> David Gerard wrote:

>> Building from master on Lenovo X240 running Xubuntu 16.04 64-bit, it
>> consistently fails with this:

> Hmm - can you paste/mail us your configure line? I have a hunch why
> that might fail...


config.log shows:

./configure --with-gdrive-client-secret=[secret]
--with-gdrive-client-id=[client-id] --prefix=/home/fun/bin/libreoffice
--with-parallelism=1 --srcdir=/home/fun/libreoffice
--enable-option-checking=fatal

autogen.lastrun is:

--with-gdrive-client-secret=[secret]
--with-gdrive-client-id=[client-id]
--prefix=/home/fun/bin/libreoffice
--with-parallelism=1

And when I try rebuilding just for this test:

$ make CppunitTest_desktop_lib
make -j 1 -rs -f /home/fun/libreoffice/Makefile.gbuild CppunitTest_desktop_lib

(I have replaced the actual secret and client-id in the above)


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Build from master failing on Xubuntu 16.04: DesktopLOKTest::testRunMacro assertion failed

[David Gerard]

Building from master on Lenovo X240 running Xubuntu 16.04 64-bit, it
consistently fails with this:


/home/fun/libreoffice/desktop/qa/desktop_lib/test_desktop_lib.cxx:2109:DesktopLOKTest::testRunMacro
assertion failed
- Expression: bGoodMacro

DesktopLOKTest::testRunMacro finished in: 0ms
test_desktop_lib.cxx:2109:Assertion
Test name: DesktopLOKTest::testRunMacro
assertion failed
- Expression: bGoodMacro

Failures !!!
Run: 37   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:
make CppunitTest_desktop_lib CPPUNITTRACE="gdb --args"
# for interactive debugging on Linux
make CppunitTest_desktop_lib VALGRIND=memcheck
# for memory checking
make CppunitTest_desktop_lib DEBUGCPPUNIT=TRUE
# for exception catching

/home/fun/libreoffice/solenv/gbuild/CppunitTest.mk:109: recipe for
target '/home/fun/libreoffice/workdir/CppunitTest/desktop_lib.test'
failed
make[1]: *** [/home/fun/libreoffice/workdir/CppunitTest/desktop_lib.test]
Error 1
Makefile:161: recipe for target 'CppunitTest_desktop_lib' failed
make: *** [CppunitTest_desktop_lib] Error 2


Same after a make clean and ccache -C. Any ideas?


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Test name: testOldComplexMerge::Import_Export_Import equality assertion failed XPath '//w:vMerge[4]' number of nodes is incorrect

[David Gerard]

Trying to build git master this morning (Xubuntu 14.04 amd64), the
build is failing as below.

This looks somewhat like the previous problem with older versions of
XPath: http://lists.freedesktop.org/archives/libreoffice/2015-April/067441.html


- d.


xmltesttools.cxx:70:Assertion
Test name: testOldComplexMerge::Import_Export_Import
equality assertion failed
- Expected: 1
- Actual  : 0
- In file:///tmp/lun3w2s8.tmp, XPath '//w:vMerge[4]' number of nodes
is incorrect

Failures !!!
Run: 108   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:

export DEBUGCPPUNIT=TRUE# for exception catching
export CPPUNITTRACE=gdb --args# for interactive debugging on Linux
export VALGRIND=memcheck# for memory checking

and retry using: make CppunitTest_sw_ooxmlexport5

make[1]: *** [/home/fun/libreoffice/workdir/CppunitTest/sw_ooxmlexport5.test]
Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [build] Error 2
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Test name: testOldComplexMerge::Import_Export_Import equality assertion failed XPath '//w:vMerge[4]' number of nodes is incorrect

[David Gerard]

Fixed by 
http://cgit.freedesktop.org/libreoffice/core/commit/?id=fc80f2fcff9871ae3c7ac9b75e3ed8f62a445906
- thanks :-)

On 18 April 2015 at 15:22, David Gerard dger...@gmail.com wrote:
 Trying to build git master this morning (Xubuntu 14.04 amd64), the
 build is failing as below.

 This looks somewhat like the previous problem with older versions of
 XPath: 
 http://lists.freedesktop.org/archives/libreoffice/2015-April/067441.html


 - d.


 xmltesttools.cxx:70:Assertion
 Test name: testOldComplexMerge::Import_Export_Import
 equality assertion failed
 - Expected: 1
 - Actual  : 0
 - In file:///tmp/lun3w2s8.tmp, XPath '//w:vMerge[4]' number of nodes
 is incorrect

 Failures !!!
 Run: 108   Failure total: 1   Failures: 1   Errors: 0

 Error: a unit test failed, please do one of:

 export DEBUGCPPUNIT=TRUE# for exception catching
 export CPPUNITTRACE=gdb --args# for interactive debugging on Linux
 export VALGRIND=memcheck# for memory checking

 and retry using: make CppunitTest_sw_ooxmlexport5

 make[1]: *** [/home/fun/libreoffice/workdir/CppunitTest/sw_ooxmlexport5.test]
 Error 1
 make[1]: *** Waiting for unfinished jobs
 make: *** [build] Error 2
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Test name: testSectionProtection::Import_Export_Import equality assertion failed (CppunitTest_sw_ooxmlexport5)

[David Gerard]

I routinely run LO master, compiled from source (because I can). I run
Xubuntu 14.04.

On my old laptop (which has successfully compiled LO from git for the
past year or so), I was getting this error:


xmltesttools.cxx:70:Assertion
Test name: testSectionProtection::Import_Export_Import
equality assertion failed
- Expected: 1
- Actual  : 2
- In file:///tmp/lu1i6q7w.tmp, XPath '//w:formProt[1]' number of
nodes is incorrect

Failures !!!
Run: 106   Failure total: 1   Failures: 1   Errors: 0

Error: a unit test failed, please do one of:

export DEBUGCPPUNIT=TRUE# for exception catching
export CPPUNITTRACE=gdb --args# for interactive debugging on Linux
export VALGRIND=memcheck# for memory checking

and retry using: make CppunitTest_sw_ooxmlexport5

make[1]: *** [/home/fun/libreoffice/workdir/CppunitTest/sw_ooxmlexport5.test]
Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [build] Error 2


I tried make clean (just in case of artifacts messing something up),
tried again and it still happened.

As it happened I got a new laptop yesterday, fresh Xubuntu, git cloned
LO afresh and tried again ... and got the same error. This has been
happening since Wednesday evening or so.

I presume because it hasn't been fixed that it's not happening for
everyone. Is it happening for anyone else?

I note this commit by Miklos Vajna, related to this error:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a54090f1ef4469cf824fcdb22c100c49d2ab7db
CppunitTest_sw_ooxmlexport5: try to make MacOSX_37-tdf-buildbot happy

Presumably this was to fix the same problem on MacOSX.

So ... what's going on with my setup? (I have both laptops here for
the weekend and can test stuff.)


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Test name: testSectionProtection::Import_Export_Import equality assertion failed (CppunitTest_sw_ooxmlexport5)

[David Gerard]

serval2...@yahoo.fr wrote:

 Should be ok now with
 http://cgit.freedesktop.org/libreoffice/core/commit/?id=514f9fc675eb3d116adb4b0a33c19c3d6e99e98b


It is indeed. Thank you all :-)


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Build for Google Docs (was: Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5')

[David Gerard]

Miklos wrote:
On Sun, Jan 25, 2015 at 04:27:12PM +, David Gerard dgerard at gmail.com 
wrote:

 I want to write a blog post saying how I did
 this - before I do so, will there be a problem putting it up with that
 secret (which is presumably the one in every TDF build)? Should I use
 another one? If so, how do I obtain another one?

Even if it's not hard to get the TDF secret from the binaries, it's not
fair to advertise them. The more widely it's known, the more probable
that someone will reuse it in some nasty application, then the
TDF-registered app ID will get shut down, making LibreOffice users sad.
See here on how to obtain your own ID:
https://developers.google.com/drive/web/about-auth
If you write a blog post about this topic, that's great, but I guess
best to not mention any ID explicitly, they are kind of a secret anyway.


OK, I'll do it that way :-)


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

[David Gerard]

On 17 December 2014 at 12:10, Andras Timar tima...@gmail.com wrote:
 On Wed, Dec 17, 2014 at 12:35 PM, David Gerard dger...@gmail.com wrote:

[making LO connect to Google Drive reliably]

 So I need to ... literally compile my credentials into LO?
 How do the Windows builds of 4.3 and 4.4beta1 work? Are you saying
 they have someone's credentials actually compiled into them?

 Yes. For TDF builds TDF credentials are compiled in. But it is not
 used for anything else, but to identify the application with Google
 Drive. It is not a personal thing.


I now have a build that connects reasonably reliably, using this line:

./autogen.sh --with-gdrive-client-secret=GYWrDtzyZQZ0_g5YoBCC6F0I
--with-gdrive-client-id=457862564325.apps.googleusercontent.com;
make


That's the TDF secret. I want to write a blog post saying how I did
this - before I do so, will there be a problem putting it up with that
secret (which is presumably the one in every TDF build)? Should I use
another one? If so, how do I obtain another one?

(also, will this stop working when Google stops doing OAuth2?)


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

[David Gerard]

(originally filed as Bug 87293, but I was redirected here)


I am attempting to build with the Google Drive connection:
./autogen.sh --enable-ext-google-docs --with-gdrive-client-secret ; make

This is happening consistently for me, building latest libreoffice-4-4
from git, if I use --enable-ext-google-docs at all:

...
[build DEP] LNK:Executable/outdevgrind
[build LNK] Executable/outdevgrind
[build DEP] LNK:Executable/vcldemo
[build LNK] Executable/vcldemo
/usr/bin/ld: 
/home/fun/libreoffice/workdir/LinkTarget/StaticLibrary/libglxtest.a(glxtest.o):
undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libdl.so:
error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[1]: *** [/home/fun/libreoffice/workdir/LinkTarget/Executable/icontest]
Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [build] Error 2


The build completes successfully on master (although in that case,
Google Drive doesn't show up as a CMIS option). The above error
happens trying to build libreoffice-4-4 for the past few days.

If I build 4.4 with just ./autogen.sh ; make then it builds.

I'm running an up-to-date Xubuntu 14.04 amd64.

If you could assist, that would be most helpful :-)


(I really, really want an LO that will connect to GDrive
transparently. The Windows build of 4.3 or 4.4beta1 connect and works
fine on Windows 7, but fail in Linux under Wine, for which I've filed
https://bugs.winehq.org/show_bug.cgi?id=37674 .)


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

[David Gerard]

Andras Timar wrote:

 --enable-ext-google-docs enables the obsolete Google Docs extension,
 you don't need that. For the built-in Google Drive support via CMIS
 you need --with-gdrive-client-secret and
 --with-google-drive-client-id. Of course, you need to register with
 Google first, and pass real, existing id and secret to autogen.sh.
 E.g. (these are fake data)
 ./autogen.sh --with-gdrive-client-secret=ldhfagfxqkjewgfzutghdgfqw
--with-google-drive-client-id=326483264627629736-23432432sfdgfdsgfds.apps.googleusercontent.com



So I need to ... literally compile my credentials into LO?

How do the Windows builds of 4.3 and 4.4beta1 work? Are you saying
they have someone's credentials actually compiled into them?


(Chris Sherlock and I are busy tracking down the build error, by the
way. So this is all leading to useful things, if not in the GDrive bit
:-) )


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Build failure in 4.4 branch with --enable-ext-google-docs on Xubuntu 14.04 amd64: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'

[David Gerard]

On 17 December 2014 at 12:10, Andras Timar tima...@gmail.com wrote:
 On Wed, Dec 17, 2014 at 12:35 PM, David Gerard dger...@gmail.com wrote:

 So I need to ... literally compile my credentials into LO?
 How do the Windows builds of 4.3 and 4.4beta1 work? Are you saying
 they have someone's credentials actually compiled into them?

 Yes. For TDF builds TDF credentials are compiled in. But it is not
 used for anything else, but to identify the application with Google
 Drive. It is not a personal thing.


That's not entirely clear to me, but OK ... it's clearly a very
experimental feature.

(I tracked down what originally led me to think that Google Drive via
CMIS was a properly-supported feature:
http://standardsandfreedom.net/index.php/2014/02/01/libreoffice42/
But with the 4.2, we also have some nice and immediately actionnable
features that will appeal specifically to the enterprise market:
Integration of the CMIS stack allowing you connect to document
repositories on SharePoint, Nuxeo, Tibco, Alfresco, Google Drive and
many other CMS ... Of course, a marketing blog isn't development. But
others have gained this impression, e.g. to the point of filing Ubuntu
bugs expecting the feature to work:
https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1389936
Some clarification of its status may be appropriate ...)

The original build problem appears to be fixed in master by
http://cgit.freedesktop.org/libreoffice/core/commit/vcl/Executable_icontest.mk?id=6e7da281c22a62ae39799b2736885e54c388caf2
- I tried that fix and it fixed my build problem, so presumably that
should go back to 4.4 branch as well (Chris Sherlock is looking into
this).


- d.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice