Summary: | eselected boost 1.35 prevents openoffice 3.2.0 from building | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Uladzimir Bely <wiselord1983> |
Component: | New packages | Assignee: | Tiziano Müller (RETIRED) <dev-zero> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | Arsen.Shnurkov, biuudresle, bugs, office, purslow, santos |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | eclass/boost-utils |
Description
Uladzimir Bely
2010-02-21 09:36:57 UTC
Indeed. Same here. In my other (amd64) box with boost-1.37.0-r1 it compiled fine. OOo uses boost-1.39.0. So it should depend on that version. They will bump to version 1.42 for windows compatibility somewhen. see http://www.openoffice.org/issues/show_bug.cgi?id=109450 Let's see if OOo or Gentoo has version 1.42 sooner. ;) Raised the dependency - as usual to the required minimum, closing *** Bug 306283 has been marked as a duplicate of this bug. *** *** Bug 306209 has been marked as a duplicate of this bug. *** My apologies if I'm missing something which should be obvious, but this problem persists for me. I resynced on Monday (22nd) & have tried deleting the distfiles which look relevant: OOo_3.2.0_src_core.tar.bz2 OOo_3.2.0_src_extensions.tar.bz2 OOo_3.2.0_src_system.tar.bz2 OOo_3.2.0_src_testautomation.tar.bz2 ooo-build-3.2.0.6.tar.gz (but not OOo_3.2.0_src_l10n.tar.bz2 , which seems unlikely to affect matters), & recompiling or simply refetching them with 'emerge -f openoffice', but the same error occurs. I have 4 slotted versions of Boost installed: 1.35.0-r5 1.36.0-r1 1.37.0-r1 1.39.0 (the 1st for OO 3.1.1 ). It's now 2010-02-24 03:46 UT & the update should have reached the mirrors: I'm not certain which file was changed, but should it not have a new date 2010-02-21, when Changelog change was made ? Thanks as always to the dev for his prompt response. Well what do you get when entering eselect boost list ? Which version is set as default? Thanks again for the prompt response: the version set was 35 , I've reset it to 36 & it has started compiling. I've never encountered this before: how is a user expected to know that s/he has to eselect the version of Boost ? why doesn't the ebuild simply check for installed versions & use the appropriate one, if it is installed ? where was the change in version required recorded in my system ? -- nothing seems to have changed in the ebuilds or distfiles since 100220 . I am always grateful for the devs' unpaid work, but sometimes users need a bit more information: please don't assume they we as much as you do (smile). Adding boost maintainer. Conclusion: OpenOffice.org build fails if ... 1. there is an old boost version installed 2. and useflag [eselect] is not set of dev-libs/boost 3. or the user selected an old version. This is prone to errors, even in future. What is the best course of action? Either remove useflag [eselect] from dev-libs/boost because everyone wants the latest version. Or add some functions to eselect-boost package for ebuilds to set latest and reset afterwards. Or ...? I hope not to rely on the user to select the correct boost version. The hack used by one ebuild at least is this: http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/visual/visual-5.13.ebuild?r1=1.1&r2=1.2 @Andreas Mind to add that to openoffice ebuild? ;) (In reply to comment #9) > 1. there is an old boost version installed > 2. and useflag [eselect] is not set of dev-libs/boost > 3. or the user selected an old version. boost-eselect is for users that use boost in their local projects. Packages should always use the highest available version and disregard eselect setting. (In reply to comment #11) > > @Andreas > Mind to add that to openoffice ebuild? ;) > Actually yes. I think it's fundamentally wrong put a workaround in each and every ebuild that uses boost. If a dependency on a certain minimal package version is not enough, this sounds pretty broken to me. @Lukasz: So how are we supposed to do that? > Actually yes. I think it's fundamentally wrong put a workaround in each and
> every ebuild that uses boost. If a dependency on a certain minimal package
> version is not enough, this sounds pretty broken to me.
I concur. That functionality (after generalization maybe) should be provided by an eclass. But with slotted boost it would never be a no-op from ebuild point of view.
(In reply to comment #13) > > Actually yes. I think it's fundamentally wrong put a workaround in each and > > every ebuild that uses boost. If a dependency on a certain minimal package > > version is not enough, this sounds pretty broken to me. > > I concur. That functionality (after generalization maybe) should be provided > by an eclass. But with slotted boost it would never be a no-op from ebuild > point of view. > Created attachment 224237 [details]
eclass/boost-utils
well, just an example eclass. i.e., one can use these functions in src_configure:
- get paths to latest available version with: add_boost_paths
- get paths to version 1.42: add_boost_paths '=142'
- get paths to a version higher than: add_boost_paths '>139'
Not in the tree anymore |