[gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
mån 2010-06-28 klockan 15:05 +0100 skrev Ciaran McCreesh: On Mon, 28 Jun 2010 14:59:21 +0100 Roy Bamford neddyseag...@gentoo.org wrote: All of engineering involves compromise. It's not a question of compromise. It's a question of being right vs being wrong. If one person says that 2 + 2 = 4 and a loud mob screams that their prophet revealed to them in a blog post that 2 + 2 = 6, you don't compromise and say that 2 + 2 = 5. Sorry for being late to the party, but: http://www.thinkgeek.com/tshirts-apparel/unisex/generic/60f5/ [1] Nothing is EVER black or white. Not even the physical ones and zeros in your computer are. That is why we have politics. To make compromises which tells us what we should parse as a one or a zero. 1. (A t-shirt saying 2 + 2 = 5. For this joke to work you have to know how to round numbers, and that 2 can be rounded from everything between 1,5 and 2,4, and that 4,8 rounds to 5. And it is still correct math.)
Re: [gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On 5 July 2010 18:31, Peter Hjalmarsson x...@rymdraket.net wrote: [...] 1. (A t-shirt saying 2 + 2 = 5. For this joke to work you have to know how to round numbers, and that 2 can be rounded from everything between 1,5 and 2,4, and that 4,8 rounds to 5. And it is still correct math.) Just to take this threat as far off-topic as I can, http://en.wikipedia.org/wiki/2_%2B_2_%3D_5 :p Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On 5 July 2010 14:01, Peter Hjalmarsson x...@rymdraket.net wrote: 1. (A t-shirt saying 2 + 2 = 5. For this joke to work you have to know how to round numbers, and that 2 can be rounded from everything between 1,5 and 2,4, and that 4,8 rounds to 5. And it is still correct math.) You said yourself that it's a joke, and yet somehow you don't seem to understand what that means
[gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
Hi, Nirbheek Chauhan nirbh...@gentoo.org: What needs to be done now is for someone with lots of CPU power to grab the list of packages[1], and build them one-by-one (all versions), adding to a new list all the ebuilds that fail. How to test: LDFLAGS=-Wl,--as-needed emerge -v1 $atom Once we have the list that fails with normal as-needed, we can fix them, get the fix upstreamed (if possible), and switch the flag on. This action should probably be accompanied by a news item informing users about the change, and encouraging them to report the (rare) bug which might hit them. And the stable tree should be safe, too. In general I like the idea. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On 06/28/2010 10:51 AM, Ciaran McCreesh wrote: On Mon, 28 Jun 2010 10:44:54 +0300 Samuli Suominenssuomi...@gentoo.org wrote: You've forgotten make --as-needed not break correct code by making the linker ignore explicit instructions from a program author to link two things together. Until you do that, --as-needed is in the same category as -ffast-math. And we can't be held hostage by few packages (marginal cases), that's why we have function called $(no-as-needed) in flag-o-matic.eclass to disable the behavior for these packages. Will Gentoo be doing the same for -Ofast and its flags then? After all, most packages work with them, and you can't let the few packages that require standard-compliant behaviour from a compiler hold Gentoo hostage. --as-needed is a flag that tries to solve a specific (and very annoying) problem. It deserves a bit of special treatment. It's not a ricer flag :-)
[gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
Ciaran McCreesh posted on Mon, 28 Jun 2010 09:16:32 +0100 as excerpted: --as-needed does not prevent breakage. It shoves some breakages under the carpet so they're sometimes less visible, and sometimes easier to fix when they happen. However, it does absolutely nothing to address any of the root causes of the breakage, and it does introduce new breakages itself. Had one tenth of the effort that had been put into running around and adding in hacks to work around a deliberately broken toolchain instead been put into fixing libtool and delivering better slotting mechanisms, none of this would be an issue. Or is the policy we've started running towards the cliff and we've already debated the merits of jumping off it, so all you're allowed to discuss now is how we remove the fence? OK, let's take that last analogy of yours, and expand it to better match rather more of the situation. The current situation is that we have a big mountain (with known unsafe cliffs) in the way of a journey we happen to make somewhat regularly. Now there's a 10 kilometer (or read mile, if you prefer) road over the mountain, with the next shortest alternative being a 110 km road around the mountain. Unfortunately, because the road over the mountain currently transits a particular cliff without tested guardrails, it's gated off (your fence) and marked with large warning signs, unguarded cliff ahead, proceed at your own risk. The 110 km road around the mountain is thus what most folks take now, with only a few deciding they can manage the risk if they go carefully (often after someone else points out the shortcut, and describes the problems so they can be careful at that cliff), and choosing to take that road. That's the current situation. Everyone seems to agree that we have the mountain, the 110 km long route around it that most folks take, and a potentially quite dangerous 10 km shortcut over it, that some few take instead. OK, as it so happens, a proposed guard rail along the dangerous parts has been surveyed, contracted, and is pretty much finished. Pretty much all that remains now is painting the stripes on the new section, and putting up the various curve left, curve right, etc, signage, and getting official sign-offs on the guard rails at an already listed set of particular sections of the cliff that need it. Except... There's a particular set of individuals that despite that almost finished section of road, only awaiting the paint, signage, and official signoffs, continues to argue that's not the /proper/ solution, that the /proper/ solution is to tunnel straight thru a particular section of the mountain, thereby bypassing the cliff entirely. In fact, not only do they claim that the tunnel is the proper solution and would in fact be less dangerous than transiting the cliff even with the guard rails is, they claim that the tunnel would have actually cost less to construct than the section of road transiting the cliff did. So here we are, playing politics at the meeting set to give the final go- ahead to complete the final inspections, the painting and the signage on the road transiting the cliff, a road that's all finished and actually in use by some already, save for that, and we still have this tunnel bloc of folks opposing it, continuing to argue that the tunnel is the /proper/ solution. Who knows at this point? The tunnel may in fact have been cheaper, and there's no question that it would have prevented the occasional careless driver still crashing thru the guard rails and going over the cliff. But the point is, we don't have that tunnel, but we do have the already basically finished road, well surveyed and already constructed, with only a bit of painting and certification left, yet the tunnel bloc is still opposing the road, arguing that the gate and warnings be maintained as they are, until that tunnel is properly finished, even at the cost of all those travelers having to take the 110 km long way around until that tunnel is completed and opened at some unpredictable time in the future, possibly a decade or more away. So yes, we ARE arguing that the final preparations be made and that the gate currently barring the way to that cliff come down. The fact of the matter is that yes, there is a cliff, but there's also a well constructed road with proper guard rails transiting that cliff, and pending the paint, signage, and final signoffs, it's ready to open and there's no reason other than the political opposition of the tunnel bloc not to make those last preparations, and then remove that gate and the warnings currently barring the way. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
On Mon, Jun 28, 2010 at 12:46:53PM +0100, David Leverton wrote: This has been pointed out ever since the issue was first discussed, but some people like to stick their fingers in their ears and dismiss legitimate technical arguments as trolling and politics. The issue is some folk are trying to be pragmatic, and some folk are sticking to it's not the proper long term solution thus don't do it at all. The question shouldn't be is it long term the right or wrong solution, the question should be yes it's not perfect, but what is the gain of deploying it? Literally, do we break more by deploying it then we gain? Is the reduction in intermediate broken packages (and general linkage whonkyness) being mostly sorted worth the cost of some cranky packages breaking from it? That is the question. If the only correct answer is it must be the right technical solution always we'd theoretically be running hurd rather than linux after all, nor would the prefix project be in wide usage. Alternatively rather than arguing, someone needs to go out and get some data to back this change (and/or back the stance it causes more damage than it's worth). Personally, I've been running as-needed for a while- while not a fan of it, it's been an overall plus for my usage. The question is if it's an overall gain to deploy globally (iirc fedora/ubuntu are running this way now). ~harring pgpNqSGT0ZRpZ.pgp Description: PGP signature
