Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
В Птн, 30/05/2008 в 20:28 -0700, Brian Harring пишет: > Either way, basically it's coming down to if gentoo wants to follow > the definition of 'academic' right, or 'pragmatic' right. Exempting > ciaran, vote seems to be pragmatic. Well, although I've asked about problems with having --as-needed by default, I'd better go with academic. C++ is quite common language to ignore its design problems and in the end it's not hard to define LDFLAGS in make.conf. -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Saturday 31 May 2008 00:16:31 Ciaran McCreesh wrote: > > Ok, then everything in the tree is covered and we can move to having > > --as-needed as default. > > Is the next version of everything in the tree covered? Have you made > sure that software isn't merely working by fluke? We interupt this thread with breaking news! A troll claims that future software packages may break! This reporter sure hopes that the developers in question actually tests packages before they commit. I, for one, welcome our new --as-needed Overlords. > Is Gentoo really that desperate to turn everyone into a ricer? Everyones ride should be pimped. Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 02:17:48 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sat, 31 May 2008 03:03:42 +0200 > Luca Barbato <[EMAIL PROTECTED]> wrote: > > Ciaran McCreesh wrote: > > > Which is where the design flaw is -- as-needed incorrectly assumes > > > that the only type of dependency between shared objects is a name > > > dependency. This isn't true with C++ static initialisers. > > > > I don't see why should be different than abusing .init in any other > > language that let you do (ok, C, C++, asm mostly). > > In C++ it's not abuse. It's using the language as specified and > designed. > Would that be possible for you (or anyone else) to point or provide example of code that breaks after use of as-needed? -- Michal Kurgan http://dev.gentoo.org/~moloh -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] packages up for grabs
many of these are low maintence ... i'd forgotten i was even listed under them as i havent seen a bug report in a long time. some i added (well probably too many) on a lark, so if they do end up being crappy and no one cares, i guess that's why we have a tree cleaners group. no herd: app-admin/durep app-arch/deltarpm app-arch/gtk-splitter app-arch/tardy app-shells/rssh app-text/doclifter dev-lang/cm3-bin dev-libs/libhash dev-libs/libmix dev-libs/libtomcrypt dev-libs/libtomfloat dev-libs/libtommath dev-libs/libtompoly dev-libs/tomsfastmath dev-util/elfsh dev-util/ghh net-ftp/glftpd net-ftp/ncftp net-libs/libvncserver net-misc/vnc net-misc/aget sys-boot/psoload media-optical herd: app-cdr/bin2iso app-cdr/ccd2iso app-cdr/plextor-tool app-cdr/pxlinux base-system herd: app-arch/unace app-editors/hexcurse dev-libs/libedit dev-util/cpuinfo-collection net-misc/ntp sys-apps/lcdsplash sys-apps/netboot-base embedded herd: app-emulation/coldfire dev-libs/matrixssl net-misc/dropbear sys-libs/uclibc perl herd: app-misc/gwine sh herd: dev-embedded/dc-tool-ip graphics herd: media-gfx/feh media-gfx/wings media-libs/amanith media-libs/esdl media-libs/giblib media-libs/svgalib video herd: media-video/came media-video/SDLcam netmon herd: net-analyzer/cryptcat net-analyzer/ffp net-analyzer/mping net-analyzer/netcat6 net-libs/libnet net-misc/netpipes net-misc/pipes net-dialup herd: net-dialup/picocom net-irc herd: net-irc/bnc net-mail herd: net-mail/freepops mobile herd: sys-apps/i2c-tools kernel-misc/toolchain herd: sys-devel/sparse m68k herd: sys-fs/atari-fdisk base-system/embedded herd: sys-fs/mtd-utils www-apps herd: www-apps/horde-chora www-apps/horde-gollem www-apps/horde-groupware www-apps/horde-imp www-apps/horde-ingo www-apps/horde-jeta www-apps/horde-kronolith www-apps/horde www-apps/horde-mimp www-apps/horde-mnemo www-apps/horde-nag www-apps/horde-passwd www-apps/horde-pear www-apps/horde-turba www-apps/horde-webmail -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, May 31, 2008 at 08:45:09AM +0530, Nirbheek Chauhan wrote: > On Sat, May 31, 2008 at 8:33 AM, Ciaran McCreesh > <[EMAIL PROTECTED]> wrote: > > On Sat, 31 May 2008 08:28:27 +0530 > > "Nirbheek Chauhan" <[EMAIL PROTECTED]> wrote: > >> Fact: It works. Unlike your vapour-proposal to "fix libtool". > > > > But it doesn't work. And fixing libtool isn't vapour. Read the Debian > > patch. > > Fixing libtool isn't vapour, neither is the debian patch, but your > plan/proposal to do is non-existant. You're just saying "Do this > because I say you should, I don't know how, but you should. Oh, and if > you don't you're all idiots". It's worth noting the debian patch was also rejected by upstream- http://lists.gnu.org/archive/html/libtool/2004-05/msg00118.html Full thread in question- http://lists.gnu.org/archive/html/libtool/2004-05/msg00097.html Basically, libtool upstream points at several rather hard issues to fixing it fully. Worth noting that was also in '04- 4 years later (with said debian patch in use), issue still is unfixed upstream. > >> Fact: Breakages are rare, code which causes it is discouraged anyway, > >> and is fixable in any case. We're not a standards organisation. > > > > You seriously think Gentoo has the manpower to go around making > > unnecessary changes to upstream code? And there's nothing in the C++ > > standard discouraging static initialisation. Considering static initialization doesn't always play nice on other platforms (porting rekall 2.2 on osx comes to mind), I'd expect the sources in question to be addressing the issue themselves frankly (which is what occured with rekall). Either way, basically it's coming down to if gentoo wants to follow the definition of 'academic' right, or 'pragmatic' right. Exempting ciaran, vote seems to be pragmatic. Cc'ing council, would like them to discuss this for upcoming meeting. ~harring pgpAvegxALtXm.pgp Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, May 31, 2008 at 8:33 AM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sat, 31 May 2008 08:28:27 +0530 > "Nirbheek Chauhan" <[EMAIL PROTECTED]> wrote: >> Fact: It can't be fixed easily and/or in a reasonable time-frame. Else >> someone would've done it -- heck you could've fixed it. > > Untrue. The amount of effort that's been wasted messing around with > as-needed could easily have been directed to fixing the root cause > instead. Debian have already done most of the work. And the time you just wasted spewing rhetoric on this thread? Since you have such a deep understanding of everything, couldn't you have done the rest of the work, posted it here and instantly convinced everyone? >> Fact: It works. Unlike your vapour-proposal to "fix libtool". > > But it doesn't work. And fixing libtool isn't vapour. Read the Debian > patch. Fixing libtool isn't vapour, neither is the debian patch, but your plan/proposal to do is non-existant. You're just saying "Do this because I say you should, I don't know how, but you should. Oh, and if you don't you're all idiots". >> Fact: Breakages are rare, code which causes it is discouraged anyway, >> and is fixable in any case. We're not a standards organisation. > > You seriously think Gentoo has the manpower to go around making > unnecessary changes to upstream code? And there's nothing in the C++ > standard discouraging static initialisation. The tracker bug (bug 129413) seems to say otherwise. >> Fact: It hasn't been done forever, and won't be done anytime soon. > > And the Debian patch is...? Useless unless it's complete. As I said above, fix it and convince us. Show us how wrong we are. We'll be glad and grateful. Don't whine about it and waste everyone's time and energy. -- ~Nirbheek Chauhan -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Fri, 30 May 2008 21:50:49 -0500 Ravi Pinjala <[EMAIL PROTECTED]> wrote: > Could you explain, for the benefit of us spectators, what these > libtool problems are, and what cleaner solution you have in mind? > It'd make this whole discussion a lot more comprehensible. libtool links against dependencies-of-dependencies, rather than just direct dependencies. This is correct behaviour on some platforms under some situations (one example is static linking). But when linking shared objects on modern Unixy platforms it's a pain in the ass since you end up with a load of bogus shared object dependencies that break things unnecessarily upon upgrades. as-needed works around this by making the linker only link things from the command line that resolve a name dependency (but name dependencies aren't the only dependency type). This means that most of the extras libtool adds in end up getting ignored, but it also means that things the programmer has explicitly said to link in get ignored too. The correct fix is to make libtool only link to dependencies of dependencies when doing, for example, static linking. Debian has a half-working patch for this that I posted earlier in the thread. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 08:28:27 +0530 "Nirbheek Chauhan" <[EMAIL PROTECTED]> wrote: > > Fact: the underlying issue is a libtool bug. > > Fact: It can't be fixed easily and/or in a reasonable time-frame. Else > someone would've done it -- heck you could've fixed it. Untrue. The amount of effort that's been wasted messing around with as-needed could easily have been directed to fixing the root cause instead. Debian have already done most of the work. > > Fact: as-needed does not fix this bug. It attempts to work around > > it. > > Fact: It works. Unlike your vapour-proposal to "fix libtool". But it doesn't work. And fixing libtool isn't vapour. Read the Debian patch. > > Fact: as-needed breaks standard-compliant code. > > Fact: Breakages are rare, code which causes it is discouraged anyway, > and is fixable in any case. We're not a standards organisation. You seriously think Gentoo has the manpower to go around making unnecessary changes to upstream code? And there's nothing in the C++ standard discouraging static initialisation. > > Fact: fixing the libtool bug would give all the benefits purportedly > > given by using as-needed, without the drawbacks. > > Fact: It hasn't been done forever, and won't be done anytime soon. And the Debian patch is...? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, May 31, 2008 at 8:03 AM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: >> Once again, you do not support your argument with anything but your >> own word. Don't make me choke on the salt please :) > > Uhm. You're suggesting that the underlying issue is not a libtool > problem? Or you're suggesting that as-needed fixes the libtool bug? > Which basic fact that everyone discussing this should already know are > you disputing? I'm disputing your claim that fixing libtool is the correct solution *right now*, and that it's sanely doable in a reasonable time-frame. The former has been questioned by pretty much everyone else in the thread, and the latter is probably false since you don't just do it yourself. > >> Once again, rhetoric and insults without logic or reason. We all know >> you know that you need facts to convince people, but you're not >> providing any facts. One can only conclude that your purpose is not to >> convince. I honestly am baffled what purpose you have in mind. > > I expect people to do their homework and understand what we're > discussing. Do you expect me to start every post by explain what a > linker is? EDOESNOTMAKESENSE You said "[...]plenty of people are quite happy to jump in and yell when they don't have the slightest clue what the root problem is[...]" I replied saying that the paragraph was full of "rhetoric and insults without logic or reason". The latter part of the post is purely about how you're doing the same even where you should be talking with facts. Your reply seriously does not make sense to me. > >> > And unfortunately, it looks like those people are the ones that're >> > going to be making the decisions. >> >> Excellent, then you are free to point and laugh when we trip and fall. >> In the meantime, if you truly think everyone is making the wrong >> decision, talk with some facts and/or statistics. > > Fact: the underlying issue is a libtool bug. Fact: It can't be fixed easily and/or in a reasonable time-frame. Else someone would've done it -- heck you could've fixed it. > > Fact: as-needed does not fix this bug. It attempts to work around it. Fact: It works. Unlike your vapour-proposal to "fix libtool". > > Fact: as-needed breaks standard-compliant code. Fact: Breakages are rare, code which causes it is discouraged anyway, and is fixable in any case. We're not a standards organisation. > > Fact: fixing the libtool bug would give all the benefits purportedly > given by using as-needed, without the drawbacks. Fact: It hasn't been done forever, and won't be done anytime soon. > > It's quite simple, and if there're any of the above that you didn't > already know then why are you wasting everyone else's time discussing > things in this thread without doing some basic research first? It's quite simple, and you already knew all of the above, so why are you wasting everyone's time and energy discussing these things in this thread? Quite refreshing, seeing you type out your points in a clear manner for clearer rebuttal. I am going to assume that the matter is settled now. -- ~Nirbheek Chauhan -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: On Sat, 31 May 2008 07:38:12 +0530 "Nirbheek Chauhan" <[EMAIL PROTECTED]> wrote: 1) You say the benefits haven't been pointed out, while several posts have already done so. You seem to be the only one pretending to be unaware of them. No no no. The benefits described would be obtained by fixing libtool. What you get from as-needed is a half-arsed sometimes-working subset of those benefits. as-needed is not the fix for the libtool problems. 2) The "expense of breaking things" is completely unqualified in your post. Here's some context: "expense" is minimal since the problem is easily fixable, and "breaking things" is the list of bugs on the tracker bug -- 19 with most of them already having patches that just need to be committed And all of which are utterly pointless. 3) You say fixing libtool is the correct solution but you don't say why or explain how. You don't give any information at all, and due to the non-existant evidence, I am going to take the statement with a fist of salt. I'm assuming everyone contributing to this thread knows exactly what the libtool problems are... But from the looks of things, plenty of people are quite happy to jump in and yell when they don't have the slightest clue what the root problem is, what as-needed changes, what as-needed breaks or how as-needed is unrelated to the problem. And unfortunately, it looks like those people are the ones that're going to be making the decisions. Could you explain, for the benefit of us spectators, what these libtool problems are, and what cleaner solution you have in mind? It'd make this whole discussion a lot more comprehensible. --Ravi -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 07:53:05 +0530 "Nirbheek Chauhan" <[EMAIL PROTECTED]> wrote: > > No no no. The benefits described would be obtained by fixing > > libtool. What you get from as-needed is a half-arsed > > sometimes-working subset of those benefits. as-needed is not the > > fix for the libtool problems. > > Once again, you do not support your argument with anything but your > own word. Don't make me choke on the salt please :) Uhm. You're suggesting that the underlying issue is not a libtool problem? Or you're suggesting that as-needed fixes the libtool bug? Which basic fact that everyone discussing this should already know are you disputing? > Once again, rhetoric and insults without logic or reason. We all know > you know that you need facts to convince people, but you're not > providing any facts. One can only conclude that your purpose is not to > convince. I honestly am baffled what purpose you have in mind. I expect people to do their homework and understand what we're discussing. Do you expect me to start every post by explain what a linker is? > > And unfortunately, it looks like those people are the ones that're > > going to be making the decisions. > > Excellent, then you are free to point and laugh when we trip and fall. > In the meantime, if you truly think everyone is making the wrong > decision, talk with some facts and/or statistics. Fact: the underlying issue is a libtool bug. Fact: as-needed does not fix this bug. It attempts to work around it. Fact: as-needed breaks standard-compliant code. Fact: fixing the libtool bug would give all the benefits purportedly given by using as-needed, without the drawbacks. It's quite simple, and if there're any of the above that you didn't already know then why are you wasting everyone else's time discussing things in this thread without doing some basic research first? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, May 31, 2008 at 7:44 AM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sat, 31 May 2008 07:38:12 +0530 > "Nirbheek Chauhan" <[EMAIL PROTECTED]> wrote: >> 1) You say the benefits haven't been pointed out, while several posts >> have already done so. You seem to be the only one pretending to be >> unaware of them. > > No no no. The benefits described would be obtained by fixing libtool. > What you get from as-needed is a half-arsed sometimes-working subset of > those benefits. as-needed is not the fix for the libtool problems. Once again, you do not support your argument with anything but your own word. Don't make me choke on the salt please :) > >> 2) The "expense of breaking things" is completely unqualified in your >> post. Here's some context: "expense" is minimal since the problem is >> easily fixable, and "breaking things" is the list of bugs on the >> tracker bug -- 19 with most of them already having patches that just >> need to be committed > > And all of which are utterly pointless. Ah, that's assuming your arguments are right, and your arguments aren't supported, so I'll take some more salt with this one. > >> 3) You say fixing libtool is the correct solution but you don't say >> why or explain how. You don't give any information at all, and due to >> the non-existant evidence, I am going to take the statement with a >> fist of salt. > > I'm assuming everyone contributing to this thread knows exactly what the > libtool problems are... But from the looks of things, plenty of people > are quite happy to jump in and yell when they don't have the slightest > clue what the root problem is, what as-needed changes, what as-needed > breaks or how as-needed is unrelated to the problem. Once again, rhetoric and insults without logic or reason. We all know you know that you need facts to convince people, but you're not providing any facts. One can only conclude that your purpose is not to convince. I honestly am baffled what purpose you have in mind. > And unfortunately, > it looks like those people are the ones that're going to be making the > decisions. Excellent, then you are free to point and laugh when we trip and fall. In the meantime, if you truly think everyone is making the wrong decision, talk with some facts and/or statistics. -- ~Nirbheek Chauhan -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 07:38:12 +0530 "Nirbheek Chauhan" <[EMAIL PROTECTED]> wrote: > 1) You say the benefits haven't been pointed out, while several posts > have already done so. You seem to be the only one pretending to be > unaware of them. No no no. The benefits described would be obtained by fixing libtool. What you get from as-needed is a half-arsed sometimes-working subset of those benefits. as-needed is not the fix for the libtool problems. > 2) The "expense of breaking things" is completely unqualified in your > post. Here's some context: "expense" is minimal since the problem is > easily fixable, and "breaking things" is the list of bugs on the > tracker bug -- 19 with most of them already having patches that just > need to be committed And all of which are utterly pointless. > 3) You say fixing libtool is the correct solution but you don't say > why or explain how. You don't give any information at all, and due to > the non-existant evidence, I am going to take the statement with a > fist of salt. I'm assuming everyone contributing to this thread knows exactly what the libtool problems are... But from the looks of things, plenty of people are quite happy to jump in and yell when they don't have the slightest clue what the root problem is, what as-needed changes, what as-needed breaks or how as-needed is unrelated to the problem. And unfortunately, it looks like those people are the ones that're going to be making the decisions. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Fri, 30 May 2008 19:01:24 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > > The correct solution is to fix libtool., but that's evidently > > beyond the abilities of people who're only interested in increasing > > their epenis size by throwing more silly options in config files. > > Then go do it. You don't like the solution folks favor because you > view another as more "correct and proper", either put up, or shut > up. Ah, brilliant. The old "yes, we know we're wrong but we're going to do it anyway so there!" approach. Nice design principle, that... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, May 31, 2008 at 7:20 AM, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Fri, 30 May 2008 18:43:56 -0700 > Brian Harring <[EMAIL PROTECTED]> wrote: >> So... folks have pointed out a benefit to using --as-needed. > > But they haven't. They've pointed out a flaw in libtool that is sort of > worked around sometimes at the expense of breaking things by using > as-needed. The correct solution is to fix libtool, but that's evidently > beyond the abilities of people who're only interested in increasing > their epenis size by throwing more silly options in config files. This is incredible. I have never seen a more logic-lacking and flamebait reply to a post full of reason and logic. 1) You say the benefits haven't been pointed out, while several posts have already done so. You seem to be the only one pretending to be unaware of them. 2) The "expense of breaking things" is completely unqualified in your post. Here's some context: "expense" is minimal since the problem is easily fixable, and "breaking things" is the list of bugs on the tracker bug -- 19 with most of them already having patches that just need to be committed 3) You say fixing libtool is the correct solution but you don't say why or explain how. You don't give any information at all, and due to the non-existant evidence, I am going to take the statement with a fist of salt. 4) epenis size? Really. You grabbed one line in his entire post and used it to divert the conversation's direction from constructive to time-wasting-argument. Personally, I agree wholeheartedly with what Brian has said. There are advantages (they've have already been stated earlier), and they far outweigh the disadvantages (breakages are easily fixable afaict). ~Nirbheek Chauhan who awaits the reply by ciaranm quoting one sentence from his post and flaming/trolling him -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, May 31, 2008 at 02:50:20AM +0100, Ciaran McCreesh wrote: > On Fri, 30 May 2008 18:43:56 -0700 > Brian Harring <[EMAIL PROTECTED]> wrote: > > So... folks have pointed out a benefit to using --as-needed. > > But they haven't. They've pointed out a flaw in libtool that is sort of > worked around sometimes at the expense of breaking things by using > as-needed. > The correct solution is to fix libtool., but that's evidently > beyond the abilities of people who're only interested in increasing > their epenis size by throwing more silly options in config files. Then go do it. You don't like the solution folks favor because you view another as more "correct and proper", either put up, or shut up. Meanwhile, obviously w/ the exemption of you and your "epenis" insults, most other folk don't seem to mind this approach as at least an interim solution- so again I ask, where are the stats stating the sky shall fall? ~harring pgpp8XFN6IweK.pgp Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Fri, 30 May 2008 18:43:56 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > So... folks have pointed out a benefit to using --as-needed. But they haven't. They've pointed out a flaw in libtool that is sort of worked around sometimes at the expense of breaking things by using as-needed. The correct solution is to fix libtool, but that's evidently beyond the abilities of people who're only interested in increasing their epenis size by throwing more silly options in config files. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
While we can continually loop around w/ the "--as-needed is evil since c++ does this one odd thing occasionally" argument, why not hear from the folks using it, specifically finding out what breaks in their usage? Ciaran: yes, just because the tree works now w/ --as-needed doesn't mean that future pkg versions will work. Dumb argument however (has shades of 'the sky is falling') since *every* new version is untested and has the potential to break against our accepted build environments (or to break pre-existing pkgs). That's a known issue, and dealt with (30 days stablization among other things). So... folks have pointed out a benefit to using --as-needed. The benefit itself doesn't seem particularly in dispute, analyze the fallout from it- if the best that is offered is "the spec says otherwise", screw the spec frankly- a .01% breakage w/ 99.99% pkgs getting a positive gain is a strong argument for doing exemptions where needed. Basically, pull out the stats of the breakage. There is *always* risk in changes (new gcc, new bash breaking paludis/portage, etc), someone kindly come back w/ stats backing their specific viewpoint. Arguing over the spec at this point isn't going anywhere, so just drop it. ~harring pgpxIxoDRqEjB.pgp Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: On Fri, 30 May 2008 15:07:43 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: I see that a number of packages in the tree explicitly filter -ffast-math. That's mostly from the bad old days when users were encouraged to use silly CFLAGS... 1. _When_ was this? 2. _Who_ was encouraging this? . . . because it sure as hell hasn't ever been in the official documentation. Last year I wrote the optimization guide[1] in part to stem the flood of bad advice on the unofficial gentoo-wiki, and by uninformed users on the forums. There hasn't been any official documentation telling users to do foolish things with their CFLAGS or LDFLAGS. [1] http://www.gentoo.org/doc/en/gcc-optimization.xml signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 03:03:42 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > Which is where the design flaw is -- as-needed incorrectly assumes > > that the only type of dependency between shared objects is a name > > dependency. This isn't true with C++ static initialisers. > > I don't see why should be different than abusing .init in any other > language that let you do (ok, C, C++, asm mostly). In C++ it's not abuse. It's using the language as specified and designed. > > Unfortunately, the ricers shoving as-needed upon everyone aren't > > smart > > Asking people to not do stuff that is unportable (Solaris and PE > based systems) seems sensible and not ricing. Not where "unportable" means "doesn't work on systems that fail to correctly implement widely used international standards" it doesn't. You might as well say "you shouldn't use lchown() because BSD 2 doesn't support it". > > enough to fix libtool, which is the real problem here, so they go > > for the thing they think they understand instead, without thinking > > the implications through -- as-needed, like fast-math, is for > > programs explicitly designed for it, not for universal use. > > Differently -ffast-math is setting up a slightly different behavior > than the usual standard, --as-needed enforce what is the default > standard in determined architectures, thus the exception and the > universality are quite reverted. Both are standard-violating options that are useful for applications designed to work with them explicitly. > We already started to think how to fix libtool, or at least make it > less annoying, removing .la files when they are not necessary. Again, that's silly ricing. Saving a few kBytes is irrelevant. Instead, you should be focusing your efforts upon something that will really make a difference, like getting something based upon this into upstream: http://patches.ubuntu.com/by-release/extracted/debian/libt/libtool/1.9+20051221-1/link_all_deplibs.dpatch -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: Which is where the design flaw is -- as-needed incorrectly assumes that the only type of dependency between shared objects is a name dependency. This isn't true with C++ static initialisers. I don't see why should be different than abusing .init in any other language that let you do (ok, C, C++, asm mostly). Unfortunately, the ricers shoving as-needed upon everyone aren't smart Asking people to not do stuff that is unportable (Solaris and PE based systems) seems sensible and not ricing. enough to fix libtool, which is the real problem here, so they go for the thing they think they understand instead, without thinking the implications through -- as-needed, like fast-math, is for programs explicitly designed for it, not for universal use. Differently -ffast-math is setting up a slightly different behavior than the usual standard, --as-needed enforce what is the default standard in determined architectures, thus the exception and the universality are quite reverted. We already started to think how to fix libtool, or at least make it less annoying, removing .la files when they are not necessary. Similarly we started proposing upstream to use pkg-config if they aren't already. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 00:47:44 +0300 Mart Raudsepp <[EMAIL PROTECTED]> wrote: > Portage developers - is there anything we should do to get --as-needed > to make.conf.example and other places, beyond fixing the known bugs on > the appropriate bug tracker? make.conf.example is no big deal, that's just documentation, though personally I'd prefer to remove the toolchain (CHOST, *FLAGS) stuff from there so we don't have to maintain all the arch-specific diffs. If you want to really enable it by default you'll have to persuade the profile maintainers to add it into the appropriate make.defaults. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 02:17:15 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > Linking with as-needed is the stage in which the elimination occurs, > > and as-needed is the cause of the elimination. So yes, it is > > related. > > The linker just does bookkeeping, if there aren't symbols used, the > library won't be in the list. Which is where the design flaw is -- as-needed incorrectly assumes that the only type of dependency between shared objects is a name dependency. This isn't true with C++ static initialisers. > >> Still, PE and ELF are older than the first C++ spec so, IFF your > >> reading of this chapter is correct, C++ is broken by design. > > > > Not at all. Read "The Design and Evolution of C++", and you shall > > see that requiring changes to the linker where necessary for > > sensible behaviour was considered acceptable, and with good reason. > > As in "we have a square wheels, let's make routes for them"... More like "getting the linker right is important enough to us that we'll pester people to make their wheels at least octagonal rather than the current square". Unfortunately, as-needed is moving back to square. > Anyway is the book a standard? Is it available as pdf so you can > point me the exact paragraph? The book is an explanation of why the standard is the way it is. You can find it at your local library. Whilst we're on the subject... You'll note that as-needed overrides explicit instructions from the programmer. When you say "link A to B", you aren't say "link A to B unless you feel like not doing the link". Unfortunately, the ricers shoving as-needed upon everyone aren't smart enough to fix libtool, which is the real problem here, so they go for the thing they think they understand instead, without thinking the implications through -- as-needed, like fast-math, is for programs explicitly designed for it, not for universal use. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: Linking with as-needed is the stage in which the elimination occurs, and as-needed is the cause of the elimination. So yes, it is related. The linker just does bookkeeping, if there aren't symbols used, the library won't be in the list. Still, PE and ELF are older than the first C++ spec so, IFF your reading of this chapter is correct, C++ is broken by design. Not at all. Read "The Design and Evolution of C++", and you shall see that requiring changes to the linker where necessary for sensible behaviour was considered acceptable, and with good reason. As in "we have a square wheels, let's make routes for them"... Anyway is the book a standard? Is it available as pdf so you can point me the exact paragraph? lu - changing the world so non euclidean aberrations fit isn't sensible -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 01:54:45 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > > ISO/IEC 14882:1998 section 3.7.1 paragraph 2. > > "If an object of static storage duration has initialization or a > destructor with side effects, it shall not be eliminated even if > it appears to be unused, except that a class object or its copy > may be eliminated as specified in 12.8." > > Unchanged in the 2003 revision. > > Is that related to linking? I don't think so. Linking with as-needed is the stage in which the elimination occurs, and as-needed is the cause of the elimination. So yes, it is related. > Still, PE and ELF are older than the first C++ spec so, IFF your > reading of this chapter is correct, C++ is broken by design. Not at all. Read "The Design and Evolution of C++", and you shall see that requiring changes to the linker where necessary for sensible behaviour was considered acceptable, and with good reason. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: On Sat, 31 May 2008 01:13:58 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: I know exactly which standard -ffast-math violates (IEEE/ISO floating point spec) and how (the man page is quite complete about this), --as-needed doesn't have any warning about this, there isn't any standard that it violates since it's the default behavior at least for 2 platform (one from those who wrote most of the ELF spec...). Point the spec, and the paragraph violated. ISO/IEC 14882:1998 section 3.7.1 paragraph 2. "If an object of static storage duration has initialization or a destructor with side effects, it shall not be eliminated even if it appears to be unused, except that a class object or its copy may be eliminated as specified in 12.8." Unchanged in the 2003 revision. Is that related to linking? I don't think so. Still, PE and ELF are older than the first C++ spec so, IFF your reading of this chapter is correct, C++ is broken by design. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Fri, 30 May 2008 16:43:38 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > > ISO/IEC 14882:1998 section 3.7.1 paragraph 2. > > Might want to confirm it's in 14882:2003, since the '98 was > withdrawn... ~harring It's in all the way up to the current 0x draft. It even has the same section and paragraph number. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, May 31, 2008 at 12:26:44AM +0100, Ciaran McCreesh wrote: > On Sat, 31 May 2008 01:13:58 +0200 > Luca Barbato <[EMAIL PROTECTED]> wrote: > > I know exactly which standard -ffast-math violates (IEEE/ISO floating > > point spec) and how (the man page is quite complete about this), > > --as-needed doesn't have any warning about this, there isn't any > > standard that it violates since it's the default behavior at least > > for 2 platform (one from those who wrote most of the ELF spec...). > > Point the spec, and the paragraph violated. > > ISO/IEC 14882:1998 section 3.7.1 paragraph 2. Might want to confirm it's in 14882:2003, since the '98 was withdrawn... ~harring pgpR1x14Lvqq4.pgp Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 01:13:58 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > I know exactly which standard -ffast-math violates (IEEE/ISO floating > point spec) and how (the man page is quite complete about this), > --as-needed doesn't have any warning about this, there isn't any > standard that it violates since it's the default behavior at least > for 2 platform (one from those who wrote most of the ELF spec...). > Point the spec, and the paragraph violated. ISO/IEC 14882:1998 section 3.7.1 paragraph 2. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: I'd bet you could get a pretty long way by shoving -ffast-math into CFLAGS by default before anyone would notice... Non sequitur. We are talking about --as-needed, not -ffast-math. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: On Fri, 30 May 2008 15:07:43 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: On 22:53 Fri 30 May , Ciaran McCreesh wrote: On Sat, 31 May 2008 00:47:44 +0300 Mart Raudsepp <[EMAIL PROTECTED]> wrote: The story that matters here is, that a C++ corner case that does not work on 0.01% of packages with --as-needed and breaks on non-ELF platforms, should not cause good things for our users to be shot down. You could say the same thing for -ffast-math... When there's a feature that only breaks one package that we know of, wouldn't it make more sense to enable it globally and add an exception than to do it the other way around? Both -ffast-math and --as-needed make the compiler / linker violate various standards in ways that can't be used safely unless a package has been explicitly designed to work with it. I know exactly which standard -ffast-math violates (IEEE/ISO floating point spec) and how (the man page is quite complete about this), --as-needed doesn't have any warning about this, there isn't any standard that it violates since it's the default behavior at least for 2 platform (one from those who wrote most of the ELF spec...). Point the spec, and the paragraph violated. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 01:08:21 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > > Except that Paludis is fine with --as-needed. > > Ok, then everything in the tree is covered and we can move to having > --as-needed as default. Is the next version of everything in the tree covered? Have you made sure that software isn't merely working by fluke? Is Gentoo really that desperate to turn everyone into a ricer? I'd bet you could get a pretty long way by shoving -ffast-math into CFLAGS by default before anyone would notice... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: On Sat, 31 May 2008 00:47:44 +0300 Mart Raudsepp <[EMAIL PROTECTED]> wrote: Paludis is fine with as-needed. But hey, don't let reality get in the way of your pathetic attempts at turning everything into Paludis bashing. It happens to be the only package that I know of that couldn't be fixed to work with --as-needed (fix for others being to actually state linking with a library whose symbols are directly used). I have not heard of anything else. Except that Paludis is fine with --as-needed. Ok, then everything in the tree is covered and we can move to having --as-needed as default. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Fri, 30 May 2008 15:07:43 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > On 22:53 Fri 30 May , Ciaran McCreesh wrote: > > On Sat, 31 May 2008 00:47:44 +0300 > > Mart Raudsepp <[EMAIL PROTECTED]> wrote: > > > The story that matters here is, that a C++ corner case that does > > > not work on 0.01% of packages with --as-needed and breaks on > > > non-ELF platforms, should not cause good things for our users to > > > be shot down. > > > > You could say the same thing for -ffast-math... > > When there's a feature that only breaks one package that we know of, > wouldn't it make more sense to enable it globally and add an > exception than to do it the other way around? Both -ffast-math and --as-needed make the compiler / linker violate various standards in ways that can't be used safely unless a package has been explicitly designed to work with it. For packages that have been explicitly designed to work with either, upstream can add the options to the build system themselves. For packages that haven't, it's not Gentoo's place to try to guess whether upstream has designed their software with ricer flags in mind, and whether if it works by fluke now it'll still work in the next version. > I see that a number of packages in the tree explicitly filter > -ffast-math. That's mostly from the bad old days when users were encouraged to use silly CFLAGS... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On 22:53 Fri 30 May , Ciaran McCreesh wrote: > On Sat, 31 May 2008 00:47:44 +0300 > Mart Raudsepp <[EMAIL PROTECTED]> wrote: > > The story that matters here is, that a C++ corner case that does not > > work on 0.01% of packages with --as-needed and breaks on non-ELF > > platforms, should not cause good things for our users to be shot down. > > You could say the same thing for -ffast-math... When there's a feature that only breaks one package that we know of, wouldn't it make more sense to enable it globally and add an exception than to do it the other way around? I see that a number of packages in the tree explicitly filter -ffast-math. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On Sat, 31 May 2008 00:47:44 +0300 Mart Raudsepp <[EMAIL PROTECTED]> wrote: > > Paludis is fine with as-needed. But hey, don't let reality get in > > the way of your pathetic attempts at turning everything into Paludis > > bashing. > > It happens to be the only package that I know of that couldn't be > fixed to work with --as-needed (fix for others being to actually > state linking with a library whose symbols are directly used). I have > not heard of anything else. Except that Paludis is fine with --as-needed. > That doesn't mean Gentoo progress, in maintainability of a running > system through the ease of ABI breaks meaning magnitudes of less > recompilations, should be inhibited. as-needed isn't the right way to do this. > > And twenty years ago C++ had to work around linkers that only > > supported eight character symbol names. Reality moves forward, > > except in situations like these where people try to rice it > > backwards. > > Maybe you'd like to tell that to the authors of the platforms that > don't support this extreme corner case, but are amongst the platforms > that we do somewhat support in Gentoo? Not really. They'll fix it sooner or later. Probably sooner, once C++0x starts being widely used. > The story that matters here is, that a C++ corner case that does not > work on 0.01% of packages with --as-needed and breaks on non-ELF > platforms, should not cause good things for our users to be shot down. You could say the same thing for -ffast-math... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
On R, 2008-05-30 at 22:37 +0100, Ciaran McCreesh wrote: > On Sat, 31 May 2008 00:31:22 +0300 > Mart Raudsepp <[EMAIL PROTECTED]> wrote: > > On R, 2008-05-30 at 20:20 +0100, Ciaran McCreesh wrote: > > > On Fri, 30 May 2008 21:13:32 +0200 > > > Luca Barbato <[EMAIL PROTECTED]> wrote: > > > > Talk to the upstream about this, probably getting a satisfying > > > > solution isn't that difficult. > > > > > > The solution is to use --as-needed in the same way that -ffast-math > > > is used: only with applications specifically designed to support it. > > > > You mean everything but paludis? > > Paludis is fine with as-needed. But hey, don't let reality get in the > way of your pathetic attempts at turning everything into Paludis > bashing. It happens to be the only package that I know of that couldn't be fixed to work with --as-needed (fix for others being to actually state linking with a library whose symbols are directly used). I have not heard of anything else. > > Doesn't your grand plan include supporting Prefix and Interix with PE > > binaries and so on? > > I have no particular interest in supporting any platform that can't > ship a Standard-compliant C++ environment. That doesn't mean Gentoo progress, in maintainability of a running system through the ease of ABI breaks meaning magnitudes of less recompilations, should be inhibited. > > I know projects that need to work around static initialization not > > being reliable - they only happen to have done that for other reasons > > (such as Windows PE format, iirc) years before --as-needed was > > implemented for binutils. > > Standards is one thing - reality is something quite different. > > The reality is that everything designed to work everywhere is just > > mighty happy with --as-needed and lots of benefits to gain from it. > > And twenty years ago C++ had to work around linkers that only supported > eight character symbol names. Reality moves forward, except in > situations like these where people try to rice it backwards. Maybe you'd like to tell that to the authors of the platforms that don't support this extreme corner case, but are amongst the platforms that we do somewhat support in Gentoo? The story that matters here is, that a C++ corner case that does not work on 0.01% of packages with --as-needed and breaks on non-ELF platforms, should not cause good things for our users to be shot down. 99.9% packages in the tree work just great with --as-needed with many benefits, including ABI break pain reduction (and less importantly memory savings from dirty library private memory pages), so given that percentage the default should be what makes things better for users with exceptions for those tiny percentage of packages that fall into the corner case (that break on more exotic platforms anyway and arguably should be fixed). Portage developers - is there anything we should do to get --as-needed to make.conf.example and other places, beyond fixing the known bugs on the appropriate bug tracker? -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On Sat, 31 May 2008 00:31:22 +0300 Mart Raudsepp <[EMAIL PROTECTED]> wrote: > On R, 2008-05-30 at 20:20 +0100, Ciaran McCreesh wrote: > > On Fri, 30 May 2008 21:13:32 +0200 > > Luca Barbato <[EMAIL PROTECTED]> wrote: > > > Talk to the upstream about this, probably getting a satisfying > > > solution isn't that difficult. > > > > The solution is to use --as-needed in the same way that -ffast-math > > is used: only with applications specifically designed to support it. > > You mean everything but paludis? Paludis is fine with as-needed. But hey, don't let reality get in the way of your pathetic attempts at turning everything into Paludis bashing. > Doesn't your grand plan include supporting Prefix and Interix with PE > binaries and so on? I have no particular interest in supporting any platform that can't ship a Standard-compliant C++ environment. > I know projects that need to work around static initialization not > being reliable - they only happen to have done that for other reasons > (such as Windows PE format, iirc) years before --as-needed was > implemented for binutils. > Standards is one thing - reality is something quite different. > The reality is that everything designed to work everywhere is just > mighty happy with --as-needed and lots of benefits to gain from it. And twenty years ago C++ had to work around linkers that only supported eight character symbol names. Reality moves forward, except in situations like these where people try to rice it backwards. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On R, 2008-05-30 at 20:20 +0100, Ciaran McCreesh wrote: > On Fri, 30 May 2008 21:13:32 +0200 > Luca Barbato <[EMAIL PROTECTED]> wrote: > > Talk to the upstream about this, probably getting a satisfying > > solution isn't that difficult. > > The solution is to use --as-needed in the same way that -ffast-math is > used: only with applications specifically designed to support it. You mean everything but paludis? Doesn't your grand plan include supporting Prefix and Interix with PE binaries and so on? I know projects that need to work around static initialization not being reliable - they only happen to have done that for other reasons (such as Windows PE format, iirc) years before --as-needed was implemented for binutils. Standards is one thing - reality is something quite different. The reality is that everything designed to work everywhere is just mighty happy with --as-needed and lots of benefits to gain from it. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On Fri, 30 May 2008 21:29:26 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > --as-needed is fundamentally broken by design and causes legitimate > > code to break. > > Basically C++ quasi-standard corner cases nobody uses, that happen to > work on ELF only and that should be removed in the next revision of > 0x ? It's going to end up being used more, not less, in 0x, thanks to constexpr and the new thread rules. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
Ciaran McCreesh wrote: --as-needed is fundamentally broken by design and causes legitimate code to break. Basically C++ quasi-standard corner cases nobody uses, that happen to work on ELF only and that should be removed in the next revision of 0x ? Implicit plugin loading isn't exactly a sane thing. lu - less excuses to laziness please. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On Fri, 30 May 2008 21:13:32 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: > Talk to the upstream about this, probably getting a satisfying > solution isn't that difficult. The solution is to use --as-needed in the same way that -ffast-math is used: only with applications specifically designed to support it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
David Leverton wrote: On Friday 30 May 2008 17:29:49 Diego 'Flameeyes' Pettenò wrote: This really is backward, solution-wise: you expect the "core application" to know enough of the plugins to link them together, but not enough to call their init functions... Why should it call their init functions, when a static object with a constructor can do the job just fine? Talk to the upstream about this, probably getting a satisfying solution isn't that difficult. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] VCS repository overview for Gentoo
This is more of a reminder email than anything else, in my capacity as the VCS administrator for Gentoo. Recently, some folk have wondered if we can come up with a better name than 'overlays', as a lot of the newer repositories aren't actually overlays of the tree, but rather independent development for Gentoo. CVS.gentoo.org: No new repositories on offer. Access for developers only. May contain private repositories. Public read-only: http://anoncvs.gentoo.org/ Browser: http://sources.gentoo.org/ SVN.gentoo.org: New repositories available on demand (request on bug #95277) Access for developers only. May contain private repositories. Public read-only: http://anonsvn.gentoo.org/ Browser: http://sources.gentoo.org/ GIT.gentoo.org: New repositories available on demand (request on bug #196025) Access for developers only. May contain private repositories. Public read-only: http://anongit.gentoo.org/ Browser: http://sources.gentoo.org/gitweb/ GIT.overlays.gentoo.org: New repositories available on demand (see webpage) External and developer access. All repositories public. URL: http://git.overlays.gentoo.org/ Browser: http://git.overlays.gentoo.org/gitweb/ SVN.overlays.gentoo.org: (formerly known just as overlays.gentoo.org) New repositories on hold, pending migration to new hardware. External and developer access. All repositories public. URL: http://www.gentoo.org/proj/en/overlays/ Browser: http://overlays.gentoo.org/ -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpUEunaqzYtt.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On Friday 30 May 2008 17:29:49 Diego 'Flameeyes' Pettenò wrote: > This really is backward, solution-wise: you expect the "core > application" to know enough of the plugins to link them together, but > not enough to call their init functions... Why should it call their init functions, when a static object with a constructor can do the job just fine? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On Fri, 30 May 2008 18:29:49 +0200 [EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote: > David Leverton <[EMAIL PROTECTED]> writes: > > It's not just the order, it also breaks things that rely on > > the .init section being called at all to register themselves with > > the core application (with --as-needed, the .so doesn't get loaded > > in the first place, so it doesn't get a chance to run anything). > > This really is backward, solution-wise: you expect the "core > application" to know enough of the plugins to link them together, but > not enough to call their init functions... Actually, no. The core application doesn't have to be doing the linking. The linking can be done by an intermediate library. > And still, it breaks not only with --as-needed but also with the Sun > linker, with the PE file format and other non-ELF file formats. So > it's really not a problem _limited_ to --as-needed. It works with any standard-compliant C++ setup. > Beside, you can _force_ a link by using --no-as-needed before a given > library, that's what it's supposed to happen if you don't want to be > helped by the linker. And next you'll be saying "and you can force a compile using --no-broken-behaviour-that-goes-against-the-standard". > To a very minimum this can be said to be a _clash_ between two > designs. Saying that --as-needed is _broken_ because it breaks this > case is _quite_ an exaggeration... Saying it's broken because it goes against an international standard isn't... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
David Leverton <[EMAIL PROTECTED]> writes: > It's not just the order, it also breaks things that rely on the .init > section being called at all to register themselves with the core > application (with --as-needed, the .so doesn't get loaded in the first > place, so it doesn't get a chance to run anything). This really is backward, solution-wise: you expect the "core application" to know enough of the plugins to link them together, but not enough to call their init functions... And still, it breaks not only with --as-needed but also with the Sun linker, with the PE file format and other non-ELF file formats. So it's really not a problem _limited_ to --as-needed. Beside, you can _force_ a link by using --no-as-needed before a given library, that's what it's supposed to happen if you don't want to be helped by the linker. To a very minimum this can be said to be a _clash_ between two designs. Saying that --as-needed is _broken_ because it breaks this case is _quite_ an exaggeration... -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpDGGzHF7XVV.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On Friday 30 May 2008 13:22:15 Diego 'Flameeyes' Pettenò wrote: > The only thing that can be broken by using --as-needed is code that > assumes the order in calling the .init sections of a set of shared > objects. Such an order is not only changed by --as-needed usage but by > any other change in the loading mechanism. It is strictly related to > glibc at this point as far as I can tell. It's not just the order, it also breaks things that rely on the .init section being called at all to register themselves with the core application (with --as-needed, the .so doesn't get loaded in the first place, so it doesn't get a chance to run anything). > It's interesting to note that Microsoft _did_ think of this problem when > designing the .NET framework, and they answer is ensuring just that the > static constructor will be called (right) before any static method or > attribute is referenced and (right) before any object of the given class > is istantiated. They don't get otherwise an absolute order in which > static constructors are called. That's /an/ answer, but it doesn't provide all the functionality that static objects in C++ have. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
Rémi Cardona <[EMAIL PROTECTED]> writes: > --as-needed breaks legitimate C++ code, I have yet to see it break > plain C code (but I could be wrong). This because C does not have constructors or static objects. I suppose I can write a couple of C files that can present the problem, but really, they would break as soon as I change the loading rules by moving to a non-ELF system or a different dynamic loader. It's interesting to note that Microsoft _did_ think of this problem when designing the .NET framework, and they answer is ensuring just that the static constructor will be called (right) before any static method or attribute is referenced and (right) before any object of the given class is istantiated. They don't get otherwise an absolute order in which static constructors are called. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgp6Q7c1XvJEy.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
Santiago M. Mola a écrit : On Fri, May 30, 2008 at 9:16 AM, Mike Auty <[EMAIL PROTECTED]> wrote: I've been using it for a pretty long time now (probably a couple weeks after Diego first blogged about it) and don't have many problems at all (now), but every once in a while a version bump or a new package will just fail to compile properly and the problem leads back to as-needed. I'm not sure whether ~arch users would be able to catch all the as-needed bugs before they hit stable, so I couldn't say whether it should be enabled by default or not. Our experience in the gnome herd is that most --as-needed issues come up *very* quickly: either the build fails, or application plugins don't get loaded. As such, they're quite easy to catch. Fixing them can be trickier. --as-needed breaking legitimate code is a problem, though. I wonder if we have that kind of code in any application in the tree and if we have some way to detect it. --as-needed breaks legitimate C++ code, I have yet to see it break plain C code (but I could be wrong). Ciaran posted an example code a while ago, either here or on his blog. His example is valid C++ code (basically it was about implicitly loading .so plugins) but IMHO, it's just not a good engineering practice. Plugin loading should be explicit (readdir + dlopen). But that's my opinion. There could be a couple other odd cases but I don't remember them. All I can say is that --as-needed *today* does much more good than harm. Cheers -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
"Santiago M. Mola" <[EMAIL PROTECTED]> writes: > --as-needed breaking legitimate code is a problem, though. I wonder if > we have that kind of code in any application in the tree and if we > have some way to detect it. You could be looking for code not supposed to work under Solaris or Windows, as the --as-needed behaviour behaves a lot like the standard Sun linker and the forced behaviour of the PE executable format. The only thing that can be broken by using --as-needed is code that assumes the order in calling the .init sections of a set of shared objects. Such an order is not only changed by --as-needed usage but by any other change in the loading mechanism. It is strictly related to glibc at this point as far as I can tell. -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpNOhQiIWOXd.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On Fri, May 30, 2008 at 9:16 AM, Mike Auty <[EMAIL PROTECTED]> wrote: > > Peter Volkov wrote: > | Is there any reason why --as-needed is not enabled "by default"? > > There's still about 18 open bugs on the tracker[1] for it. You can see > how many problems it had been causing by the huge number of blocking bugs. > > I've been using it for a pretty long time now (probably a couple weeks > after Diego first blogged about it) and don't have many problems at all > (now), but every once in a while a version bump or a new package will > just fail to compile properly and the problem leads back to as-needed. > I'm not sure whether ~arch users would be able to catch all the > as-needed bugs before they hit stable, so I couldn't say whether it > should be enabled by default or not. That's not a problem at all. If we choose to support --as-needed by default we'd get testing from maintainers when adding new ebuilds, and from arch teams before ebuilds hit stable. --as-needed breaking legitimate code is a problem, though. I wonder if we have that kind of code in any application in the tree and if we have some way to detect it. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
Marius Mauch <[EMAIL PROTECTED]> writes: > That's what `emerge @preserved-rebuild` does, or do you mean something > different? I meant something different, see the rst. > Well, with preserve-libs the situation is this (using your example): > - user upgrades expat, portage keeps libexpat.so.0 around > (some packages might now be linked against both versions if the session > included other packages as well) > - emerge tells the user to rebuild all affected packages (affected = > contains libexpat.so.0 in NEEDED, so includes both libfoo and bar) by > using `emerge @preserved-rebuild` (in the future this could also be done > automatically, but that won't be before 2.2 final) > - when all affected packages have been rebuilt (so their NEEDED entries > don't contain libexpat.so.0 anymore) libexpat.so.0 is automatically > removed Okay this works if the user follows the procedure and tries not to bend the rules... > So, if I understand you correctly (probably not), you want portage to > prevent the user from building any packages depending on any affected > package before the last step is completed? Yes this is exactly what I meant. Whenever a dependency is in the @preserved-rebuild set, it should not be linked against. It could still be used, but as now we don't have an easy way to distinguish between the two, I'd say it's better to check both DEPEND and RDEPEND and disallow its usage as a dependency until it's removed from the set. > Whoever that is is welcome to voice his opinion here, that's the point > of this thread after all. (It was mostly a disclaimer so that users don't feel like they get ignored without just cause if they want behaviour X and instead we go with behaviour Y... I'm sure a lot of people wouldn't like the option I proposed above, but trust me there's a reason why I voiced that concern :) ). -- Diego "Flameeyes" Pettenò http://blog.flameeyes.eu/ pgpblyTC9Kg3X.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
On Fri, 30 May 2008 10:55:51 +0400 Peter Volkov <[EMAIL PROTECTED]> wrote: > В Чтв, 29/05/2008 в 11:02 +0200, Diego 'Flameeyes' Pettenò пишет: > > I'm afraid that it will turn, for complex libraries like libexpat > > and users not using --as-needed, the message telling you the > > program cannot be started with subtle crashes for symbol collision. > > Is there any reason why --as-needed is not enabled "by default"? --as-needed is fundamentally broken by design and causes legitimate code to break. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Volkov wrote: | Is there any reason why --as-needed is not enabled "by default"? There's still about 18 open bugs on the tracker[1] for it. You can see how many problems it had been causing by the huge number of blocking bugs. I've been using it for a pretty long time now (probably a couple weeks after Diego first blogged about it) and don't have many problems at all (now), but every once in a while a version bump or a new package will just fail to compile properly and the problem leads back to as-needed. I'm not sure whether ~arch users would be able to catch all the as-needed bugs before they hit stable, so I couldn't say whether it should be enabled by default or not. I also don't think it would completely eliminate the problems that Diego mentioned with preserve-libs (there could still be instances where bar and foo both NEEDED thing.so, but bar had been compiled more recently and needed thing.so.1 whilst foo needed thing.so.0, and starting bar would break trying to load both)... Mike 5:) [1] http://bugs.gentoo.org/show_bug.cgi?id=129413 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkg/qb4ACgkQu7rWomwgFXpl7wCdFhDuZbQOVy1b12dgXbZbSWtj dIMAn3Z6FDx5HW1KD83JxdboNrQOOap1 =Nca2 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
