>> I've been getting the same silly OpenOffice compile error for a couple >> weeks now. Nothing I can search up or think of seems to do the trick.
>> Here's the end of the output during compile: >> >> 1 module(s): >> unoxml >> need(s) to be rebuilt > > I had hoped to never ever see this error again, looks like my hopes were > dashed. > > Long answer: The reason for the failure is in the build log, but it is never > just above the error message. It is often many 1000s of lines higher. > bugs.gentoo.org is infested with bug reports of this kind of thing, to get any > meaningful answer you *MUST* follow the instructions in the ebuild and build > with "MAKEOPTS=-j1", also switch off distcc and cachecc as well. Using the ebuild instructions for building, the compile still fails, but the error above the fail is very slightly more useful: Entering /var/tmp/portage/app-office/openoffice-3.1.1/work/ooo/build/ooo310-m19/unoxml/source/rdf 217 Compiling: unoxml/unxlngi6/misc/unordf_dflt_version.c 218 Compiling: unoxml/source/rdf/CBlankNode.cxx 219 Compiling: unoxml/source/rdf/CURI.cxx 220 Compiling: unoxml/source/rdf/CLiteral.cxx 221 Compiling: unoxml/source/rdf/librdf_repository.cxx 222 Compiling: unoxml/source/rdf/librdf_services.cxx 223 Making: libunordfli.so 224 : ERROR: ../../unxlngi6.pro/lib/check_libunordfli.so: undefined symbol: librdf_free_storage 225 dmake: Error code 1, while making '../../unxlngi6.pro/lib/libunordfli.so' 226 227 ERROR: Error 65280 occurred while making /var/tmp/portage/app-office/openoffice-3.1.1/work/ooo/build/ooo310-m19/unoxml/source/rdf 228 rmdir /tmp/30017 229 make: *** [stamp/build] Error 1 So we at least can say that redland libraries are somehow related to the problem at hand. The only similar error I could find on google (http://www.mail-archive.com/allb...@openoffice.org/msg391683.html) appears independent of OO and implicates libcrypto as a problem. With this information in mind, I re-emerged redland and openssl (libcrypto belongs to openssl). I was digging through the emerge logs, and I have successful builds of OO-3.0.0 from a couple months ago. The thing that is very interesting is that code that is failing in 3.1.1 (librdf_*.cxx) was never even compiled in 3.0.0! The objects are there, the C++ codes are patched, but they are never compiled according to the emerge log. Having read the similar error from redland, I also notice something else suspicious: Log from 3.0.0 successful build: checking which redland library to use... internal Log from 3.1.1 failed build: checking which redland library to use... external If you didn't read the link on the only similar bug I googled, here is an excerpt: > Building (with o3-build) fails because redland links agains the system's > version > of libcrypt. It later fails in unoxml because the linked-in lib is not found > anymore: The error itself is quite similar, although the undefined reference itself is different (excerpt from above link): > Checking DLL ../../unxlngi6.pro/lib/check_libunordfli.so ...: ERROR: > libcrypto.so.0.9.6: cannot open shared object file: No such file or directory > dmake: Error code 1, while making ´../../unxlngi6.pro/lib/libunordfli.so´ So why is OO using the external (system) redland libraries which are later not found, and how can I force it to use the internal redland libraries? (Please note: for this discussion, "external library" is the same as "system library") There's no use flag, but the openoffice ebuild suggests: # Upstream this echo "--with-system-redland" >> ${CONFFILE} I should note that in the 3.0.0 and 3.0.1 ebuilds (I have them on backup -- they were removed from portage) redland is not a direct dependency of OO, and in fact, if you search the older ebuilds for 'redland' you won't find any occurrences. So, time to comment that line out, ebuild digest, and /var/log... | tail -f | grep redland checking which redland library to use... internal Now I wait for the compile. I suspect at least something should be different this time. Will post with a further report since this issue seems more serious than I at first suspected. Also..Walt: I checked all the java items as suggested, but nothing was out of place to my eye; thanks for the sanity check, though. Regards, daid
