Gentoo Archives: gentoo-dev

From: Georg Rudoy <0xd34df00d@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/boost: boost-1.46.1-r1.ebuild metadata.xml boost-1.49.0-r1.ebuild boost-1.51.0-r1.ebuild ChangeLog boost-1.47.0.ebuild boost-1.35.0-r2.ebuild boost-1.47.0-r1.ebuild boost-1.39.0.ebui
Date: Thu, 01 Nov 2012 15:00:57
Message-Id: CAGbUWS+MerV4HZewVUarRsKVocdtckqhdje9K5xp1u=c7=bofA@mail.gmail.com
In Reply to: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/boost: boost-1.46.1-r1.ebuild metadata.xml boost-1.49.0-r1.ebuild boost-1.51.0-r1.ebuild ChangeLog boost-1.47.0.ebuild boost-1.35.0-r2.ebuild boost-1.47.0-r1.ebuild boost-1.39.0.ebui by Ian Stakenvicius
1 2012/11/1 Ian Stakenvicius <axs@g.o>:
2 > On 01/11/12 10:10 AM, Georg Rudoy wrote:
3 >> 2012/11/1 Jamie Learmonth <jamie-lists@×××××××××××××.com>:
4 > This idea wouldn't work tho -- providing the old boost as binaries
5 > isn't actually going to help things, unless they are fully static, as
6 > it's the breakage against the toolchain that invalidates them
7 > (otherwise it wouldn't be an issue to leave 'em in the tree and for
8 > that matter leave boost slotted and have all rdeps just depend on the
9 > slot they were written for). And fully static binary packages are
10 > just plain wrong on any number of levels for something like this imo.
11
12 Moreover, one may run into serious runtime troubles if several copies
13 of one static library are loaded into the same address space. So, this
14 cannot be decided for all packages IMO, rather on per-package basis
15 with opt-in strategy.
16
17 --
18 Georg Rudoy
19 LeechCraft — http://leechcraft.org