libreoffice-4.2.6

[Fernando de Oliveira]

​http://download.documentfoundation.org/libreoffice/src/4.2.6/

​http://download.documentfoundation.org/libreoffice/src/4.2.6/libreoffice-4.2.6.2.tar.xz

[Armin K]

Has anyone been able to build this? I keep getting

Makefile:197: *** fetch__Download_item: libreoffice-dictionaries-4.3.0.4.tar.xz is empty.  Stop.

No matter what I try.

[christopher]

Replying to Krejzi:

Has anyone been able to build this? I keep getting

Makefile:197: *** fetch__Download_item: libreoffice-dictionaries-4.3.0.4.tar.xz is empty.  Stop.

No matter what I try.

Well I am trying it now and I am getting

:fetchDownload_item: libreoffice-translations-4.3.0.4.tar.xz is empty.

[Fernando de Oliveira]

I passed this point, hit two more errors but now it is building, used very not elegant procedure. Don't know if will complete.

Assume help and translations will be used.

After reaching the first error above (necessary, to load the packages or additional ones, if you have the previous version ones).

Restart the build from what follows:

      tar xf $SOURCEDIR/libreoffice-translations-$VERSION.$COMP_EXT \
          --no-overwrite-dir --strip-components=1                   &&
      tar xf $SOURCEDIR/libreoffice-help-$VERSION.$COMP_EXT         \
          --no-overwrite-dir --strip-components=1                   &&
      ./autogen.sh ... --disable-fetch-external                     &&
      make build

Notice the switch switch --disable-fetch-external.

Dictionaries have not been uncompressed, so I may reach a problem, and need to untar that, too.

If that works, building in other machines could start with the --disable-fetch-external all uncompressed, so that should not produce an error.

If everything is correct, it would be good to introduce a previous step in the book just to download, and start the real build already with -disable-fetch-external, if other solution does not appear.

[christopher]

Replying to fo:

I passed this point, hit two more errors but now it is building, used very not elegant procedure. Don't know if will complete.

Assume help and translations will be used.

After reaching the first error above (necessary, to load the packages or additional ones, if you have the previous version ones).

Restart the build from what follows:

      tar xf $SOURCEDIR/libreoffice-translations-$VERSION.$COMP_EXT \
          --no-overwrite-dir --strip-components=1                   &&
      tar xf $SOURCEDIR/libreoffice-help-$VERSION.$COMP_EXT         \
          --no-overwrite-dir --strip-components=1                   &&
      ./autogen.sh ... --disable-fetch-external                     &&
      make build

Notice the switch switch --disable-fetch-external.

Dictionaries have not been uncompressed, so I may reach a problem, and need to untar that, too.

If that works, building in other machines could start with the --disable-fetch-external all uncompressed, so that should not produce an error.

If everything is correct, it would be good to introduce a previous step in the book just to download, and start the real build already with -disable-fetch-external, if other solution does not appear.

Well I have checked out their git version and have yet to hit any errors. It is building perfectly so far. I have used the same options as online book though as it is git I did not create the sym-links to the dictionaries or the translation files.

[Fernando de Oliveira]

Build completed successfully. I cannot install and test immediately.

[Fernando de Oliveira]

Build of comment 5 (and later install and test) was in LFS-7.1. Always start LO there, to compare with build with new tool chains.

This morning, woke up and had the unpleasant surprise that build on LFS svn (gcc still 4.9.0) failed.

I was so optimistic, that tried to build it with -j1, so could immediately update the page.

Instead of running twice ./autogen.sh, I found the following would work (don't know if the sed could be the source for the error):

make -j1 fetch || true &&
sed 's/^fetch: get-submodules/#&/' -i Makefile &&
make -j1 build &&

The part with fetch practically was not tested, not sure if it would work without trying to build, because the download had already been done, and only the fetch errors described in previous comments appeared. I was planning to test it in the faster LFS-7.1, afterwards.

The sed makes the fetch (and consequent error) to be skipped.

Tail of error log:

[build LNK] CppunitTest/libtest_cppcanvas_emfplus.so
[build CUT] cppcanvas_emfplus
unknown:0:Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

##Failure Location unknown## : Error
Test name: Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

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

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 CPPUNITTRACE="\"[full path to devenv.exe]\" /debugexe" \
# for interactive debugging in Visual Studio
export VALGRIND=memcheck            # for memory checking

and retry using: make CppunitTest_cppcanvas_emfplus

/tmp/libreoffice-4.3.0.4/solenv/gbuild/CppunitTest.mk:70: recipe for target \
'/tmp/libreoffice-4.3.0.4/workdir/CppunitTest/cppcanvas_emfplus.test' failed
make[1]: *** [/tmp/libreoffice-4.3.0.4/workdir/CppunitTest/cppcanvas_emfplus.test] \
Error 1
Makefile:224: recipe for target 'build' failed

real	539m26.441s
user	488m3.121s
sys	49m3.551s

(I replaced the full build path ~/tmp/paco... by /tmp and broke the lines, for easier reading.)

I am suspecting again gcc, but have not started trying to study this problem.

Help from both of you or anybody else is strongly welcome, please.

[christopher]

Replying to fo:

Build of comment 5 (and later install and test) was in LFS-7.1. Always start LO there, to compare with build with new tool chains.

This morning, woke up and had the unpleasant surprise that build on LFS svn (gcc still 4.9.0) failed.

I was so optimistic, that tried to build it with -j1, so could immediately update the page.

Instead of running twice ./autogen.sh, I found the following would work (don't know if the sed could be the source for the error):

make -j1 fetch || true &&
sed 's/^fetch: get-submodules/#&/' -i Makefile &&
make -j1 build &&

The part with fetch practically was not tested, not sure if it would work without trying to build, because the download had already been done, and only the fetch errors described in previous comments appeared. I was planning to test it in the faster LFS-7.1, afterwards.

The sed makes the fetch (and consequent error) to be skipped.

Tail of error log:

[build LNK] CppunitTest/libtest_cppcanvas_emfplus.so
[build CUT] cppcanvas_emfplus
unknown:0:Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

##Failure Location unknown## : Error
Test name: Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

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

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 CPPUNITTRACE="\"[full path to devenv.exe]\" /debugexe" \
# for interactive debugging in Visual Studio
export VALGRIND=memcheck            # for memory checking

and retry using: make CppunitTest_cppcanvas_emfplus

/tmp/libreoffice-4.3.0.4/solenv/gbuild/CppunitTest.mk:70: recipe for target \
'/tmp/libreoffice-4.3.0.4/workdir/CppunitTest/cppcanvas_emfplus.test' failed
make[1]: *** [/tmp/libreoffice-4.3.0.4/workdir/CppunitTest/cppcanvas_emfplus.test] \
Error 1
Makefile:224: recipe for target 'build' failed

real	539m26.441s
user	488m3.121s
sys	49m3.551s

(I replaced the full build path ~/tmp/paco... by /tmp and broke the lines, for easier reading.)

I am suspecting again gcc, but have not started trying to study this problem.

Help from both of you or anybody else is strongly welcome, please.

Sadly my attempt at installation failed at the installed stage with missing file errors.

I think that it is safe to say at this point at least, that it will not install. I will try again with updating the git checked out code, but that won't be for a while yet. With freeze coming up I am building the latest blfs systemd book.

[Armin K]

We don't really need ugly workarounds and hacks to build a package that was working before. I'll bother upstream and let them fix it because it was them who broke it.

[Fernando de Oliveira]

Good idea, thanks. I would add my name to the bug report, but perhaps it is not suitable, because we are both from the same distribution, what do you think?

However, th error that I hit in the build is still due to gcc-4.9.0, so will try later to search for a fix, unless you think it is not.

Meanwhile, I need to do other personal business always needed in the beginning of the months.

[Armin K]

​https://bugs.freedesktop.org/show_bug.cgi?id=82136

[Armin K]

Unrelated to this issue, but please add your voice to this one too:

​https://bugs.freedesktop.org/show_bug.cgi?id=82137

[Armin K]

The main issue has been fixed upstream. The following update to the instructions is needed (attached).

[Fernando de Oliveira]

Thanks, Armin. First, for the bug report and discussion with LO developers, so we have the fix (comment 11)

Second, for the attachment.

I had noticed that they moved form src to /external/tarbals.

Interesting, that during build, it checks for src, if it is there it mves to ;external/trbals and symlink sr to there.

I tried to build without the gcc patch (after reading your comment in the bug report) and when came back, it had failed. So, will have to start again.

Will add my voice in Bug 82137.

[Armin K]

I have noticed that packages get downloaded to external/tarballs so I switched to using that one. If you use src, the symlinks will become invalid as soon as they are moved (unless you use the current ones with src, which is pointless because they get moved anyways).

[Fernando de Oliveira]

No, no, I was not clear: I completely agree with you, thanks for the patch, intend to use it.

Was just expressing that I found it also, and it was already modified in my script, your patch saved me the time to edit those places where it was src.

Bad news is that I cannot, again, build libreoffice, failed with the same message of comment:7

IIRC, previous version failed only for 32bit, my case here, too.

I think Christopher uses 32bit, so, I would like to know if you, Christopher, succeeded building it.

At this point, I am as desperate as in the previous long standing problem of previous version. Will investigate, but any help would be much welcome.

[Fernando de Oliveira]

Replying to Krejzi:

the symlinks will become invalid as soon as they are moved (unless you use the current ones with src, which is pointless because they get moved anyways).

Forgot to write: the symlink points to external/tarballs, as you know, but when running again autogen.sh or make, not sure wich one, a new src symlink is made, now inside the preivious one, so, inside external/tarballs, and the process is repeated again and again. It is imperative to modify as in your patch, thanks again

[Fernando de Oliveira]

Replying to Krejzi:

Unrelated to this issue, but please add your voice to this one too:

​https://bugs.freedesktop.org/show_bug.cgi?id=82137

Forgot that. Did it a while ago,

[Fernando de Oliveira]

Replying to fo:

I cannot build this package. I am now using gcc-4.9.1, with the same problem. The two bugs that Armin reported have been quickly fixed. The bug introduced by gcc-4.9.0 and reported at 2014-05-02 06:36 UTC by Jürg Billeter Failure and that I added my name is still not being considered. Error is always the same described at comment 7:

Tail of error log:

[build LNK] CppunitTest/libtest_cppcanvas_emfplus.so
[build CUT] cppcanvas_emfplus
unknown:0:Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

##Failure Location unknown## : Error
Test name: Test::testFdo77229
An uncaught exception of type com.sun.star.uno.RuntimeException
- PresenterCanvas: invalid number of arguments

...

real 539m26.441s user 488m3.121s sys 49m3.551s }}}

Last statistics (I included many system libraries)

real	125m54.732s
user	883m58.519s
sys	72m44.200s

I am getting tired of this. It is more important solving this than most complaints that have been recently made. Yyesterday there was a very "important" discussion about it" about "gcc version should be a wild card", and I was accused of error, when it was intentional and not an error.

I am really getting tired. I need help here, but people are more keen to find "errors" so "important", that they believe BLFS should stop being published if they are not fixed or the editor should be crucified.

Will try to do some investigation about problem of LO and nothing else, until it is fixed.

Tired, tired.

[Armin K]

Try building with clang. Note that building with clang fails on x86_64 though.

[Fernando de Oliveira]

Thanks, Armin. Will try tomorrow. Today I'm really without courage of doing any work. Not even searching for solutions. If I get tired of being in bed, will try later today.

[Fernando de Oliveira]

Replying to Krejzi:

Try building with clang. Note that building with clang fails on x86_64 though.

I forgot I have a commented line for that, and could have done before, thanks.

But as before, it fails and earlier than gcc.

I am leaving this ticket open, anybody wanting to solve build in i686 is welcome.

I have lost a lot of time, effort and courage with this and previous LO. I am inclined of not trying next ones.

It is a shame not having such important package updated in the book, more yet, having next release with an old version.

[Armin K]

In the mean time, we can bump to 4.2.6, now marked as libreoffice-still.

DocumentFoundation started offering 2 version to download - still and fresh. Fresh is what is currently 4.3.0, latest release with new features but few regressions. Still is a more mature version, with more point releases and more testing, what is currently 4.2.6.

[Fernando de Oliveira]

OK. I noticed that, but failed to have this good idea.

Will try, thanks.