app-office/openoffice-3.1.1 emerge fails as follows: Entering /var/tmp/portage/app-office/openoffice-3.1.1/work/ooo/build/ooo310-m19/unoxml/source/rdf Compiling: unoxml/unxlngi6/misc/unordf_dflt_version.c Compiling: unoxml/source/rdf/CBlankNode.cxx Compiling: unoxml/source/rdf/CURI.cxx Compiling: unoxml/source/rdf/CLiteral.cxx Compiling: unoxml/source/rdf/librdf_repository.cxx Compiling: unoxml/source/rdf/librdf_services.cxx Making: libunordfli.so : ERROR: ../../unxlngi6.pro/lib/check_libunordfli.so: undefined symbol: librdf_free_storage dmake: Error code 1, while making '../../unxlngi6.pro/lib/libunordfli.so' ERROR: Error 65280 occurred while making /var/tmp/portage/app-office/openoffice-3.1.1/work/ooo/build/ooo310-m19/unoxml/source/rdf rmdir /tmp/32403 make: *** [stamp/build] Error 1 * * ERROR: app-office/openoffice-3.1.1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 5273: Called die * The specific snippet of code: * make || die "Build failed" * The die message: * Build failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/app-office:openoffice-3.1.1:20091130-205328.log'. * The ebuild environment file is located at '/var/tmp/portage/app-office/openoffice-3.1.1/temp/environment'. * !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.17" JAVACFLAGS="-source 1.5 -target 1.5" COMPILER="" However, if I compile using the internal redland libraries, the compile is successful and OO.o will run. I achieve this by editing the OO.o ebuild and commenting out the line: echo "--with-system-redland" >> ${CONFFILE} Reproducible: Always Steps to Reproduce: 1. Try to emerge OO.o-3.1.1 using the portage ebuilds and system redland 2. Fail 3. Use internal redland libs and OO.o will compile Actual Results: I cannot emerge OO.o without manually editing the ebuild to use internal redland libs. Expected Results: The portage OO.o ebuild compiles using my system redland as specified in the ebuild. The world is deep updated, revdep-rebuild reports no broken linking, and dev-libs/redland-1.0.9-r1 is installed. java-check-environment reports back sane. There appear to be some traces of sun-jdk-1.4 on the system (see emerge --info), but it was unmerged some time ago. RAM and diskspace are not a problem. A related bug was filed upstream and discussed in the linked URL (18 months old); it fails on a libcrypto link which is not my case, but the behavior appears similar. After a successful compile, I reverted the ebuild to using the system redland and it fails, isolating the problem to this point on my system. Build logs for success and fail as well as emerge --info to follow.
Created attachment 211643 [details] OO.o emerge log bz2 with failure Uses system redland and portage ebuild bz2
Created attachment 211644 [details] OO.o emerge log bz2 with success ebuild is modified to force default of internal redland. bz2
Created attachment 211646 [details] emerge --info
Sorry, I forgot to note that on the successful build I received the notice: * QA Notice: * Package openoffice is breaking /usr/share/config permissions. * Please report this issue to gentoo bugzilla. * Permissions will get adjusted automatically now.
During all this, I have not gotten involved with the GNU patch-2.6 issues, just so you know. $ emerge patch These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-devel/patch-2.5.9 USE="-static" 0 kB
Identical error here on x86, except that I do not have any Java installed. This is a recent problem; openoffice-3.1.1 emerged happily when it went stable, but it now fails as reported here. Disabling USE flag for kde does not fix things. -- Regards, Mick
(In reply to comment #6) > Identical error here on x86, except that I do not have any Java installed. > This is a recent problem; openoffice-3.1.1 emerged happily when it went stable, > but it now fails as reported here. Disabling USE flag for kde does not fix > things. Can you confirm if using the OO.o internal redland libraries allows you to successfully compile? Just comment out line 304 of the ebuild (the one specifying system redland), and ebuild the manifest. Since you report originally compiling OO.o-3.1.1 successfully, then perhaps it's the system redland that is buggy? The OO.o ebuild specifies the dependency as >=dev-libs/redland-1.0.8 where as the only one in portage now is 1.0.9-r1. According to the Changelog, that version of redland went x86 stable on 19 September 2009. On 18 August redland-1.0.9-r1 was patched upstream for an error with librdf_storage_register_factory. Since the error is occurring with the librdf, it could be related here. Can you check your OO.o elogs and determine the successful build date? I have redland-1.0.8 ebuild in a backup, so I will try to build OO.o with that and report back in a few hours. Can anyone get me the redland-1.0.9 ebuild? I don't have that one for testing this.
(In reply to comment #7) > I have redland-1.0.8 ebuild in a backup, so I will try to build OO.o with that > and report back in a few hours. > > Can anyone get me the redland-1.0.9 ebuild? I don't have that one for testing > this. OO.o fails identically using system redland-1.0.8. Found redland-1.0.9.ebuild, but not going to test it yet. Thinking it may be rasqal or raptor. raptor-1.4.19 was stablized on x86 27 Sep 2009, where as rasqal-0.9.16 was stablized 14 May 2009. Going to emerge raptor-1.4.18 from backup ebuilds, rebuild redland-1.0.9-r1 and try to build OO.o again with system redland.
(In reply to comment #8) > Thinking it may be rasqal or raptor. raptor-1.4.19 was stablized on x86 27 Sep > 2009, where as rasqal-0.9.16 was stablized 14 May 2009. Going to emerge > raptor-1.4.18 from backup ebuilds, rebuild redland-1.0.9-r1 and try to build > OO.o again with system redland. > Using an older version of raptor did not alter the compile error (had rebuild redland and rasqal after raptor downgrade). No other tests strike me as obvious, because the stabilization (x86) of these other changes occur long before OO.o was stabilized, meaning it is unlikely that they would be mixed on my system. Hoping someone else has ideas so I don't need to leave OO.o as a local overlay...
Latest in tree now, =dev-libs/rasqal-0.9.17 =dev-libs/redland-1.0.10-r1 =media-libs/raptor-1.4.20
(In reply to comment #10) > Latest in tree now, > > =dev-libs/rasqal-0.9.17 > =dev-libs/redland-1.0.10-r1 > =media-libs/raptor-1.4.20 > Current dependencies: media-libs/raptor-1.4.20 USE="unicode xml -curl -debug" 0 kB dev-libs/rasqal-0.9.17 USE="pcre xml -gmp -test" 0 kB dev-libs/redland-1.0.10-r2 USE="berkdb mysql ssl xml -iodbc -odbc -postgres -sqlite" 0 kB I get similar error for openoffice-3.2.0. (Never checked further building on OO.o 3.1.1) Entering /var/tmp/portage/app-office/openoffice-3.2.0/work/ooo/build/OOO320_m12/unoxml/source/rdf Compiling: unoxml/unxlngi6/misc/unordf_dflt_version.c Compiling: unoxml/source/rdf/CBlankNode.cxx Compiling: unoxml/source/rdf/CURI.cxx Compiling: unoxml/source/rdf/CLiteral.cxx Compiling: unoxml/source/rdf/librdf_repository.cxx Compiling: unoxml/source/rdf/librdf_services.cxx Making: libunordfli.so : ERROR: libCore.so.5.22: cannot open shared object file: No such file or directory dmake: Error code 1, while making '../../unxlngi6.pro/lib/libunordfli.so' ERROR: Error 65280 occurred while making /var/tmp/portage/app-office/openoffice-3.2.0/work/ooo/build/OOO320_m12/unoxml/source/rdf rmdir /var/tmp/portage/app-office/openoffice-3.2.0/temp/fIpy7H0xlw make: *** [stamp/build] Error 1 * ERROR: app-office/openoffice-3.2.0 failed: * Build failed * * Call stack: * ebuild.sh, line 54: Called src_compile * environment, line 5512: Called die * The specific snippet of code: * make || die "Build failed" * * If you need support, post the output of 'emerge --info =app-office/openoffice-3.2.0', * the complete build log and the output of 'emerge -pqv =app-office/openoffice-3.2.0'. !!! When you file a bug report, please include the following information: GENTOO_VM=sun-jdk-1.6 CLASSPATH="" JAVA_HOME="/opt/sun-jdk-1.6.0.18" JAVACFLAGS="-source 1.5 -target 1.5" COMPILER="" and of course, the output of emerge --info * The complete build log is located at '/var/log/portage/app-office:openoffice-3.2.0:20100226-172454.log'. * The ebuild environment file is located at '/var/tmp/portage/app-office/openoffice-3.2.0/temp/environment'. * S: '/var/tmp/portage/app-office/openoffice-3.2.0/work/ooo' >>> Failed to emerge app-office/openoffice-3.2.0, Log file: >>> '/var/log/portage/app-office:openoffice-3.2.0:20100226-172454.log' Will attach log file for build. Error occurs using system redland, and successful compile occurs if I edit the OO.o ebuild so it uses the internal redland.
Created attachment 221509 [details] Build log fail for OO.o 3.2.0 bzip2 compression
(In reply to comment #11) > > Error occurs using system redland, and successful compile occurs if I edit the > OO.o ebuild so it uses the internal redland. The current ebuild in portage does already use internal redland...
(In reply to comment #13) > (In reply to comment #11) > > > > Error occurs using system redland, and successful compile occurs if I edit the > > OO.o ebuild so it uses the internal redland. > > The current ebuild in portage does already use internal redland... This could be a nomenclature issue. Here I use "external redland" to mean system redland, and "internal redland" to mean "OO.o included redland." Within the OO.o community, I believe my terminology is consistent, but please advise if it is confusing. In any case, most certainly the recent OO.o ebuilds are using the *system* redland, which is impossible to build on my system, and the main point this bug report refers to. To be clear: You may confirm that of the openoffice-3.2.0.ebuild, line 269 reads: echo "--with-system-redland" >> ${CONFFILE} Or in openoffice-3.1.1.ebuild, line 302 reads: echo "--with-system-redland" >> ${CONFFILE} This means the OO.o is using an external redland, or system redland, which I have never successfully used to compile OO.o. I must manually comment out these lines in my local ebuilds in order to successfully compile OO.o.
(In reply to comment #13) > (In reply to comment #11) > > > > Error occurs using system redland, and successful compile occurs if I edit the > > OO.o ebuild so it uses the internal redland. > > The current ebuild in portage does already use internal redland... > For example, if one considers the case when the line: echo "--with-system-redland" >> ${CONFFILE} is introduced to portage OO.o ebuilds (after 3.0.1 AFAIK), before that time, during configuration during the build, one may see from 3.0.0 (successful) build log: checking which redland library to use... internal However, once reliance on the system redland is hardcoded to the ebuild (such as in OO.o ebuild 3.1.1) my log from 3.1.1 (failed) build shows: checking which redland library to use... external Hence, the nomenclature I've chosen to adopt for this bug report.
The nomenclature is right, but obviously you didn't sync recently ;-) The most current version of the openoffice 3.2.0 ebuild in portage reads the corresponding line as: #echo "--with-system-redland" >> ${CONFFILE} So system-redland is commented out (for other bugs), this change was made 3 days ago.
(In reply to comment #16) > The nomenclature is right, but obviously you didn't sync recently ;-) The most > current version of the openoffice 3.2.0 ebuild in portage reads the > corresponding line as: > > #echo "--with-system-redland" >> ${CONFFILE} > > So system-redland is commented out (for other bugs), this change was made 3 > days ago. > Huh, I sync'ed 3.5 days ago says emerge.log So, as long as OO.o ebuilds use the internal redland, this bug can be considered fixed until that change is retracted. I lack experience in bugzilla, so the correct resolution action is not clear to me. However, as the opener of the bug, if the ebuild now reads as such, I consider my bug no longer relevant. Since I'm not up on the other related bugs with redland & OO.o, could I get those personally emailed or posted to me here? Thanks!
Ancient bug, not even in portage anymore
(In reply to comment #18) > Ancient bug, not even in portage anymore > Yes, but the suggested fix has been done for other reasons after this bugfile, without any comparison of samebug notions. I'll have to do a lot of searching to find the ebuild that also decided system redland was a bad idea and commented. Probably it was the same bug seen here without reference. OO.o and libreoffice still use the tactic to comment the upstream suggestion of system redland in the ebuild, so it could be "ancient" but I bet you if you uncomment that line in the ebuild on many systems you can still get this bug on many cases. I am happy for the close, but I think calling it ancient is a misnomer. It was a bug that plagued many things in different ways, but just the bugzilla cross referencing was not done.
(In reply to comment #19) > (In reply to comment #18) > > Ancient bug, not even in portage anymore > > > > Yes, but the suggested fix has been done for other reasons after this bugfile, > without any comparison of samebug notions. OO.o Gentoo ChangeLog: 25 Feb 2010; Andreas Proschofsky <suka@gentoo.org> openoffice-3.2.0.ebuild: Disable system-redland for now, causes troubles, see http://qa.openoffice.org/issues/show_bug.cgi?id=108911 The upstream bug cited is essentially this bug, only they reported it three months later than I did, and with more specific knowledge of the internals of redland. > libreoffice still use the tactic to comment the upstream suggestion of system > redland in the ebuild This is false. OO.o does this. LibreOffice does not. Thus, the bug now applies to libreoffice-3.3.0 until the external system redland is patched as suggested upstream. So, "speaking of the devil," of course I hit this bug yesterday in libreoffice-3.3.0. Build errors to be attached, but it's the exact same bug, and I used the exact same fix. Except that the libreoffice-3.3.0 ebuild does not fetch redland or rasqal binaries, and thus without modifying the ebuild to this end, the build will fail, since as the ebuild is written, it is incapable to properly use the build flag --without-system-redland. I skip that build fail for now. libreoffice-3.3.0 ebuild (v 2.0 if you like) to be attached with text showing the diff Of course, since the system redland works for some people, the most elegant solution is a redland USE flag, which determines if LibreOffice uses the internal or external ones. > so it could be "ancient" but I bet you if you uncomment > that line in the ebuild on many systems you can still get this bug on many > cases. Bingo! In fact, that line is used by default in libreoffice, so the bug is even current.
Created attachment 263241 [details] libreoffice-3.3.0 build log with failed external redland
Created attachment 263243 [details, diff] patch to fix LO-3.3.0 ebuild for redland internal
Created attachment 263245 [details] emerge --info
Please retry with 3.4.2.2 or later, as it works for me just peachy on system redland.
This definitely is fixed with current release of libreoffice, closing
(In reply to comment #25) > This definitely is fixed with current release of libreoffice, closing Yes. My days of recompiling are over!
