This is a large package and build failures do not occur until well into the build process. Painfully slow. :) So let's move one step at a time. I would like to ignore previous koffice FTBFS reports. Start clean, now that the core packages all build and we have a known foundation and baseline.
The first failure errors seem to be related to wv2, an MS Word import package.
I'm still building packages on Slackware 12.2. That release came with wv2 0.2.3. Release 13.0 uses 0.2.3. The wv2 package was updated to 0.4.2 in Slackware 13.1.
Unless there is no choice, I believe 12.2 and 13.0 users should not have to update the wv2 package to build or install koffice. Certainly that might be required, but I prefer to work from the thesis that Trinity KDE should build and install on previous KDE 3.5.10 distros without such tinkering.
Previously we thought the failure was caused by an old version of wv2. Yet Lenny uses the same 0.2.3 version. Trinity koffice builds for that operating system. Thus we should proceed with the presumption the problem is not wv2 directly but the build process. As we have discovered the past several weeks, what builds on Debian does not always build on Slackware without some modifications. We don't know why but that is not important right now. :)
When I build koffice on 12.2 with wv2 0.2.3 installed, the first fatal build errors I receive:
document.cpp:393: error: 'const struct wvWare::Word97::BRC' has no member named 'cv'
I'm no C++ programmer, but seems some constants are not being used correctly or as expected or are not being declared correctly.
Note: Koffice builds successfully with no errors when wv2 is not installed.
I suspect only a few people will be interested in that version. Most people want basic MS Word import functions.
Log attached!
Darrell
<snip>
I'm still building packages on Slackware 12.2. That release came with wv2 0.2.3. Release 13.0 uses 0.2.3. The wv2 package was updated to 0.4.2 in Slackware 13.1.
Unless there is no choice, I believe 12.2 and 13.0 users should not have to update the wv2 package to build or install koffice. Certainly that might be required, but I prefer to work from the thesis that Trinity KDE should build and install on previous KDE 3.5.10 distros without such tinkering.
Previously we thought the failure was caused by an old version of wv2. Yet Lenny uses the same 0.2.3 version. Trinity koffice builds for that operating system.
<snip>
I provide the newer version of wv2 for Lenny in the dependencies PPA. There were significant differences between the two APIs that forced the following changes in SVN: r1082110 r1082138 r1082651
As I think I mentioned before the build failure is most likely due to the missing .la file from the newer version of wv2. If you really want to use the older version, you will need to reverse the previous three patches (which could be done automatically) before koffice will build. What I would do is copy the koffice source, reverse patch the copy, then run a diff between the original and the copy. You can then automatically apply that single diff file to the source prior to build as part of your build script. Other distros have had to do similar hacks over time as the official KDE sources migrated to new versions of system libraries; this situation is quite similar.
Hope this helps!
Tim
There were significant differences between the two APIs that forced the following changes in SVN: r1082110 r1082138 r1082651
As I think I mentioned before the build failure is most likely due to the missing .la file from the newer version of wv2. If you really want to use the older version, you will need to reverse the previous three patches (which could be done automatically) before koffice will build. What I would do is copy the koffice source, reverse patch the copy, then run a diff between the original and the copy. You can then automatically apply that single diff file to the source prior to build as part of your build script. Other distros have had to do similar hacks over time as the official KDE sources migrated to new versions of system libraries; this situation is quite similar.
Thanks for the info. I'll work on both. I think a build for 12.2 should support the stock installation. I can provide users a warning. Thus, I'll try building with 0.4.3 too. I can modify the build script to detect which version is installed and then apply the patch as necessary. Then users can choose which version they want to build or download.
I only wish the failure occurred sooner in the process. The failure does not occur until an hour and a half into the build, probably close to the end of the process. There is no way to expedite the process so this might take day or two. :(
On Thursday 16 September 2010 02:13:50 Darrell Anderson wrote:
[...]
I only wish the failure occurred sooner in the process. The failure does not occur until an hour and a half into the build, probably close to the end of the process. There is no way to expedite the process so this might take day or two. :(
You should use ccache, this will speed-up rebuilding a lot (maybe 10 times or more)
http://en.wikipedia.org/wiki/Ccache
Although I successfully built koffice with wv2-0.2.3 installed, by reversing the respective patches applied in SVN, you said that version is broken and inadequate. Therefore I replaced 0.2.3 with 0.4.2 and tried building koffice.
FTBFS.
libtool: link: `/usr/lib/libwv2.la' is not a valid libtool archive
My apologies but I can't find in the list digest our past conversations regarding that specific error.
This seems to be a common error message with compiling.
The file is installed and not missing. That excludes that common explanation for the error message, but the build log does not say the file is missing. :)
The Debian package list does not include the la file (http://packages.debian.org/squeeze/i386/libwv2-4/filelist). Curiouser and curiouser.
The la files are nothing but text files. The la files between the two versions are different, but I don't know what to fix.
Conspicuous is the 'shouldnotlink' directives. In 0.2.3 that directive is no and in 0.4.2 the directive is yes.
I'm just guessing here. I changed the 0.4.2 directive to no and tried to build.
Another noticeable difference is the 0.4.2 la file does not contain a header statement about being a libtool library file. that missing header statement would correlate with the build error message that the file is not valid.
One other noticeable difference. The 0.4.2 build script uses cmake and not make. Might that be a clue?
Should I delete the 0.4.2 la file before trying to build koffice? Will that affect any other build that tries to compile against wv2-0.4.2?
In 0.2.3 the files in /usr/lib:
-rwxr-xr-x 1 root root 1147 2007-02-15 23:40 /usr/lib/libwv2.la* lrwxrwxrwx 1 root root 15 2008-03-14 07:29 /usr/lib/libwv2.so -> libwv2.so.1.0.8* lrwxrwxrwx 1 root root 15 2008-03-14 07:29 /usr/lib/libwv2.so.1 -> libwv2.so.1.0.8* -rwxr-xr-x 1 root root 611808 2007-02-15 23:40 /usr/lib/libwv2.so.1.0.8*
In 0.4.2:
-rwxr-xr-x 1 root root 804 2010-09-11 12:50 /usr/lib/libwv2.la* lrwxrwxrwx 1 root root 11 2010-09-17 00:30 /usr/lib/libwv2.so -> libwv2.so.4* lrwxrwxrwx 1 root root 15 2010-09-17 00:30 /usr/lib/libwv2.so.4 -> libwv2.so.4.0.1* -rwxr-xr-x 1 root root 828328 2010-09-11 12:51 /usr/lib/libwv2.so.4.0.1*
The 0.2.3 libwv2.la:
========================================================= # libwv2.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.18 (1.1220.2.245 2005/05/16 08:55:27) # # Please DO NOT delete this file! # It is necessary for linking the library.
# The name that we can dlopen(3). dlname='libwv2.so.1'
# Names of this library. library_names='libwv2.so.1.0.8 libwv2.so.1 libwv2.so'
# The name of the static archive. old_library=''
# Libraries that this one depends upon. dependency_libs=' /usr/lib/libgsf-1.la /usr/lib/libgobject-2.0.la /usr/lib/libxml2.la -lbz2 /usr/lib/libgobject-2.0.la /usr/lib/libglib-2.0.la /usr/lib/libxml2.la -ldl -lz /usr/lib/libglib-2.0.la /usr/lib/libstdc++.la -L/usr/i486-slackware-linux/bin -L/usr/i486-slackware-linux/lib -L/usr/lib/gcc/i486-slackware-linux/../../../i486-slackware-linux/lib -L/usr/lib/gcc/i486-slackware-linux/../..'
# Version information for libwv2. current=1 age=0 revision=8
# Is this an already installed library? installed=yes
# Should we warn about portability when linking against -modules? shouldnotlink=no
# Files to dlopen/dlpreopen dlopen='' dlpreopen=''
# Directory that this library needs to be installed in: libdir='/usr/lib' =========================================================
The 0.4.2 libwv2.la:
========================================================= # Please DO NOT delete this file! # It is necessary for linking the library with libtool.
# The name that we can dlopen(3). dlname='libwv2.so'
# Names of this library. library_names='libwv2.so.4.0.1 libwv2.so.4 libwv2.so'
# The name of the static archive. old_library=''
# Libraries that this one depends upon. dependency_libs=' -lz -lgsf-1 -lc -lglib-2.0'
# Names of additional weak libraries provided by this library weak_library_names=''
# Version information for /dev/shm/wv2-0.4.2/build/libwv2.la. current=4 age=0 revision=1
# Is this an already installed library? installed=yes
# Should we warn about portability when linking against -modules? shouldnotlink=yes
# Files to dlopen/dlpreopen dlopen='' dlpreopen=''
# Directory that this library needs to be installed in: libdir='/usr/lib' =========================================================
Conspicuous is the 'shouldnotlink' directives. In 0.2.3 that directive is no and in 0.4.2 the directive is yes.
I'm just guessing here. I changed the 0.4.2 directive to no and tried to build.
FTBFS.
Another noticeable difference is the 0.4.2 la file does not contain a header statement about being a libtool library file. that missing header statement would correlate with the build error message that the file is not valid.
I copied this header statement from 0.2.3 to 0.4.2:
# libwv2.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.18 (1.1220.2.245 2005/05/16 08:55:27)
koffice built. File size is slightly larger, which probably is correct. I haven't yet tested the MS Word import features, but for the moment I'll presume the package compiled correctly.
I'll take a wild guess only the first line in that header statement is necessary.
wv2-0.4.2 was not introduced into Slackware until release 13.1. The problems I am experiencing with the package would not be discovered in that release because KDE 4 is included and not 3.5. Hence, the build bug with the missing header statement is unlikely to surface with that release.
As wv2-0.4.2 is built with cmake, I don't know how the libwv2.la file gets created during the build process. I could rebuild that package and try to learn.
Questions:
Am I correct Debian does not include a libwv2.la file in its package?
Should I try to build koffice without that la file installed?
<snip>
Questions:
Am I correct Debian does not include a libwv2.la file in its package?
Debian *does* include a libwv2.la file--see below.
Should I try to build koffice without that la file installed?
Not until KOffice is ported to CMake; it won't work without the .la file when using Automake.
Tim
Not until KOffice is ported to CMake; it won't work without the .la file when using Automake.
Then the libwv2.la file is broken. Whether broken upstream or during my build I don't know. I will have to patch that file with a headder statement.
Not until KOffice is ported to CMake; it won't work without the .la file when using Automake.
Then the libwv2.la file is broken. Whether broken upstream or during my build I don't know. I will have to patch that file with a headder statement.
Upstream. I ran into something similar with libwibble (a Debian APT interface package). The .la files are being phased out from most Linux distributions, which is why the port to CMake is becoming more and more critical. Thankfully we already have someone who is willing to work on that port here. ;-)
Tim
I now can build koffice with either wv2-0.2.3 or wv2-0.4.2.
If 0.2.3 is installed my build script reverses the three Trinity patches.
If 0.4.2 is installed the script patches the installed libwv2.la file (missing header statement).
In my wv2-0.4.2 build script I patch libwv2.la before creating the final package.
Comments and notes added to the build scripts and associated help file.
Whew!
I provide the newer version of wv2 for Lenny in the dependencies PPA. There were significant differences between the two APIs that forced the following changes in SVN: r1082110 r1082138 r1082651
Woohoo! I modified the build script so that if wv2-0.2.3 is detected, to reverse the three patches. Koffice compiled.
Took 109 minutes!
Next step is to install wv2 0.4.2 and then try to build again.
-
Darrell Anderson -
Serghei Amelian -
Timothy Pearson