Re: [gentoo-user] OO fails with useless 65280 error on unoxml

[daid kahl]

>> 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/allbugs@××××××××××.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