Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On 7/7/06, Seemant Kulleen <[EMAIL PROTECTED]> wrote: I think the Council idea is great. However, I think the Council should be charged with a little bit of direction-setting and leadership as well. [...] 1. The council was (by design?) a reactive force, rather than a pro-active force. [...] This project needs some leadership, as the events of the past few months show fairly clearly. Agreed. We could decide we do not elect the council members based on their coding skills or any other type of technical skill. But instead have the nominees do some campaigning before the elections, and make direction-setting propositions for the coming year. Another thing that bothers me is the possible overlapping between council members, trustees and devrel. I wouldn't mind at all that any dev could only be one of these at most at the same time. I know that resigning from a position won't end the relationship between you and your ex-fellow devs from the group you've just quit, but at least functionally the link doesn't exist anymore. Plus, taking into account that we have a life outside of gentoo, and that these functions are the critical ones, having only one of these positions means a better chance to be efficient. Denis. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote: > On Thursday 06 July 2006 16:14, Harald van Dijk wrote: > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches > > don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported > > compiler in Gentoo. > > you're just griping because i forced ssp/pie regardless of USE=vanilla ... I didn't mind that you applied ssp/pie patches regardless of USE=vanilla, I did mind that you applied the stub patches with USE="nossp vanilla", and I also didn't like that this was either done accidentally but ignored when pointed out, or that this was done deliberately with a misleading cvs log message. > since gcc-4.0 and below are on the way out, i have no problem changing this > behavior > > besides, since both of these technologies are in mainline gcc now, i really > dont see how you can continue to gripe with gcc-4.1.1+ I don't know how much gcc-spec-env.patch can be trusted, and even if it is 100% safe, such patches don't belong in anything that would be called "vanilla". (I have commented on that patch long before this thread started, so don't think I'm just looking for something to complain about now.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage: missing pieces
On 7/6/06, Molle Bestefich <[EMAIL PROTECTED]> wrote: Evolution depends on Mozilla and Mono depends on SeaMonkey. I don't think this is right, at least not for what is currently in portage. When I do a USE="mono" emerge -Devp evolution No mozilla comes in. So evolution does not depend on mozilla, at least not directly. In fact, in the current portage tree, mozilla is going away, and being replaced by seamonkey. Very few (and hard masked) packages like gecko-sdk still depend on mozilla. So what you should eventually end up with is no mozilla but seamonkey. So I'm stuck here. Is it impossible to have Mono and Evolution installed at the same time? No, it is certainly possible, as I have both on my system. Are you using an portage overlay? If so, what is in it? When was the last time you did an emerge --sync? Also, the full output of "emerge -Duvpt world" would still be useful for us to see. -Richard -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Off with your heads!
@devs, If your blog is being aggregated on Planet Gentoo / Universe, it's time to send us a copy of your smiling face. I'm putting out a request for some hackergotchis. Really, you don't want just a few of us to have all the fun, do you? Basically, I want to get some bobble heads up on the Planet Gentoo website, since ours is pathetically blank without them. I don't care how ugly you look in real life, it's all in good fun, and it helps to put a face to the names. So, if you can, make your own hackergotchi, or send me a cartoon or something that you'd like up there in its place. Don't make me resort to drastic measures[1]. ;) If you're not a master of the Gimp, just post a photo on your blog asking for help and hopefully someone will step forward and lend a hand. Or you can try it yourself. The wikipedia entry[2] has some great links at the bottom on how to make your own. Just send them to me when you're done, and I'll post them up on the Planet for all to see and enjoy. Thanks guys :) Steve 1. http://dev.gentoo.org/~beandog/missing.png 2. http://en.wikipedia.org/wiki/Hackergotchi -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 03:15, Mike Frysinger wrote: > > x86_64 toolchain accepting 3dnow on a nocona arch? :) > that isnt a cross-compile nor a different architecture This is the whole point of my solution. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpUJ4qne0Opb.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 20:57, Diego 'Flameeyes' Pettenò wrote: > I'm just saying that I wouldn't discard entirely a solution just because > some unsupported software _might_ not work (note the conditional). I > wouldn't discard a solution just because it _might_ not work on > GNU/kFreeBSD; I would discard it if I _know for sure_ that it does not work > on GNU/kFreeBSD (in which case, knowing it doesn't work, I would look for a > working solution). you missed the point of my reply ... flatly discarding anything because we dont currently support it is a bad place to be what i was implying wasnt for you to discard an entire solution, just be more flexible forward thinking is what has allowed Gentoo to be trivially ported to what was once considered unsupported (i know it's helped a ton in porting to obscure cpus :P) now, put that in your pipe and smoke it -mike pgpIjLpGAKBcz.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 20:58, Diego 'Flameeyes' Pettenò wrote: > On Friday 07 July 2006 02:50, Mike Frysinger wrote: > > as for "broken binaries", i kind of doubt that statement ... when was the > > last time you saw a cross-toolchain accept assembly code written for a > > different architecture ? > > x86_64 toolchain accepting 3dnow on a nocona arch? :) that isnt a cross-compile nor a different architecture -mike pgpslfNlSOCyX.pgp Description: PGP signature
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
Hi Everyone, I just wanted to put a few thoughts out there as people contemplate nominees and the elections for the Gentoo Council. I personally am on the fence about running this year, because I think there are a lot of talented people who *should* be on the council. Now that I've said that (the "*should*" bit), let me expand on its meaning a little. I think the Council idea is great. However, I think the Council should be charged with a little bit of direction-setting and leadership as well. In the past year, the council did make some decisions, and helped to mediate some controversial issues. There were a couple of things which I thought were lacking, however: 1. The council was (by design?) a reactive force, rather than a pro-active force. 2. There's no way to follow through on the Council's decisions. I think these points involve *every* gentoo developer (and would-be developer) and not just the Council. If you have a GLEP or an idea and it gets approved by the council, now what? That's the thing: follow through on it! A question is, perhaps, should the council follow-up with previously approved GLEPs and inquire as to status updates? For an exemplar of the way I think the council should be is Spanky/vapier. Solar also does this well. Both of them take a leadership role in general in the project and are generally respected and admired for it. They both have great ideas and a vision. I think that should be explored further. This project needs some leadership, as the events of the past few months show fairly clearly. Thanks for listening, -- Seemant Kulleen <[EMAIL PROTECTED]> Gentoo Foundation / Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 02:50, Mike Frysinger wrote: > as for "broken binaries", i kind of doubt that statement ... when was the > last time you saw a cross-toolchain accept assembly code written for a > different architecture ? x86_64 toolchain accepting 3dnow on a nocona arch? :) -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpAcDjtAydac.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 02:46, Mike Frysinger wrote: > this sort of closed mindedness isnt really encouraging ... Err I actually thought if icc in the first place and tried to inform myself. I'm not the kind of person (and you should know) who likes breaking unsupported stuff. I think it's reasonable to find a solution that works with ICC, and actually Harald already gave one later in the thread. It's just a matter of fact that we don't have anybody right now to follow what might and might not break this or that unsupported compiler. As soon as there is a single person ready to at least answer to questions about it, the situation changes. I'm just saying that I wouldn't discard entirely a solution just because some unsupported software _might_ not work (note the conditional). I wouldn't discard a solution just because it _might_ not work on GNU/kFreeBSD; I would discard it if I _know for sure_ that it does not work on GNU/kFreeBSD (in which case, knowing it doesn't work, I would look for a working solution). -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp3WfZaRwdgm.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 10:03, Simon Stelling wrote: > c) This is not about "regaining" control. Currently, users who want to > cross-compile are screwed and need nasty use.mask-hacks to not end up > with broken binaries. The inability to provide per-package CFLAGS is a > missing feature in portage, it's got nothing to do with this issue. deficiency in portage that is being slowly resolved ... this is hardly specific to cpu-based USE flags and deserves nothing short of a real fix on the portage side as for "broken binaries", i kind of doubt that statement ... when was the last time you saw a cross-toolchain accept assembly code written for a different architecture ? now if you had said broken builds, i would have agreed with you slightly ... but again, refer to the "this is hardly specific to cpu-based USE flags" statement from earlier -mike pgprEBFPQrs3P.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 07:48, Diego 'Flameeyes' Pettenò wrote: > On Thursday 06 July 2006 13:40, Donnie Berkholz wrote: > > How will you handle non-gcc compilers? > > We don't support any, to start with. this sort of closed mindedness isnt really encouraging ... plus it's kind of funny, this statement coming from you of all people ... especially after all the crap you had to go through to break the "we dont support anything other than linux / gnu" mentality you fought through for so long -mike pgpyc9XdRhWdo.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, 7 Jul 2006 02:08:57 +0200 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: | On Friday 07 July 2006 01:54, Ciaran McCreesh wrote: | > With __PIC__ there's not much choice. Here there is. | | I would rather say that __PIC__ is guaranteed. *shrug* if you like. The __MMX__ things, however, are not. | > | No, we never spent years telling them not to use your so-called | > | "CFLAGS hacks" that are rather a proper usage of what the compiler | > | gives you. | > | > Wrong. We did. | | Then you were wrong. I could have spent time explaining them when | they make sense and why they don't in their usecases. If you did, | well, then you really need to know better what you do because you | seem to me pretty confused yourself, and I feel pity for you. Nope. We did it because a) it's unnecessary, b) some of the -m switches lead to broken code with various gcc versions and c) the only people doing it were those who didn't understand the implications. | > Basic software engineering principles. Or basic English, if you | > prefer. | | Sorry I'm in the "Software engineering does not make real world | usable" club. And find such terms opinable, subjective and vague. They're more than sufficient and entirely appropriate for the purpose at hand. Dismissing arguments by arguing about the English isn't dismissing the technical concerns. | No it does not, as one would expect the big problems being hashed out | first and then fine grained. But maybe I'm just a different kind of | practical person than you are. Or you are not a practical person at | all and just think of software engineering and theories and "this | should work this way even if there is no real world way to make use | of it" oh wait... Uh, so now you're claiming that "simplicity" and "transparency" are just handwaving? *sigh* This really isn't going to go anywhere. I hope someone else manages to explain to you the issue with replacing a couple of aptly named variables with a different misappropriated variable and a bunch of nasty complicated code relying upon an external's internals, because there's far too much mess out there already... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Diego 'Flameeyes' Pettenò wrote: > I'm waiting to see a sample implementation tho, as that is what we should > base > on. > Assuming your cpuset it is just either ( use $1 && has_cpuset $1 ) or the other way around, nothing much to write. The more I think about the issue and the more I like the complete profiles for amd64 more than the other solutions. lu lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 02:20, Danny van Dyk wrote: > Ehm, no. Athlon64 can also optionally include: sse3 (for latest > steppings) and xchg16 (which is a bit older already) That is the point, if they ask "-march=athlon64" they get the base athlon64. If you add "-msse3" (as you should if you have an Athlon64 capable of SSE3) you get the whole stuff with sse3 support too. For free! > Afaik Pentium4 has support for xchg16 since the very beginning. I don't remember any useflag for that, and I don't seem to find that instruction reported in gcc's documentation, so I cannot comment on that. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpzcsyxKLcjT.pgp Description: PGP signature
Re: [gentoo-dev] Re: Portage: missing pieces
> (Same story with OpenSSH and pam-login. OpenSSH wants shadow, and > pam-login refuses to merge alongside shadow. I want both pam-login > and OpenSSH, but seems like I'll have to choose, right?) pam-login is now included in shadow, you no longer need to emerge it. -- Pierre Guinoiseau Email: [EMAIL PROTECTED] M$N: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
Patrick Lauer wrote: > lu_zero Diego 'Flameeyes' Pettenò wrote: > And add my nominations for lu_zero I accept the nomination. I'd add to the pot pvdabeel and pylon since was and still is a pleasure working with them =) lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 02:01, Luca Barbato wrote: > Using a proper profile and not hardwire useflags to use amd64 is a > solution too. Yes it is, I would more likely see that than adding even more useflags to profiles. > > So using -march=i586 with mmx useflag wouldn't work anymore. > ...I don't see why not since gas is supposed to accepth -m* flags > related (see man as) Uh, -march=i586 will tell gas to accept only instructions present on i586, even if they come out of inline asm. If the inline asm is MMX, gas refuses to produce code. It would only work with nasm sources. > but isn't the only way and as I told you already I'd rather have stuff > properly set in profiles specific even if I like the idea of being able > to check for compiler support. Yes, you told me, and this is why we're not here discussing that. I told you want I think of the idea, I don't dislike it although I find it (thinking as it is now) a bit more complex. I'm waiting to see a sample implementation tho, as that is what we should base on. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpKj2tjLDPuq.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
Am Donnerstag, 6. Juli 2006 20:07 schrieb Diego 'Flameeyes' Pettenò: > > > rather than doing what the user says (aren't you always yelling at > > upstreams for doing that?) > > The user asks for athlon64 support? They get athlon64 (mmx, 3dnow, > 3dnowex, sse, sse2) Ehm, no. Athlon64 can also optionally include: sse3 (for latest steppings) and xchg16 (which is a bit older already) > The user asks for G3 support? They get G3 (nothing) > The user asks for Pentium4 support? They get what they want (mmx, > sse, sse2, sse3 in case) Afaik Pentium4 has support for xchg16 since the very beginning. Danny -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 01:54, Ciaran McCreesh wrote: > With __PIC__ there's not much choice. Here there is. I would rather say that __PIC__ is guaranteed. > In the VIS case, there are plenty of situations where GCC will think > that the underlying system doesn't do VIS (because that's the only way > of stopping it from producing broken code), but where hand-crafted VIS > code is fine and desirable. Okay, this is why i wanted to know that from SPARC team, as I have no knowledge of that architecture. I suppose then that VIS cannot be handled by this way. > | No, we never spent years telling them not to use your so-called > | "CFLAGS hacks" that are rather a proper usage of what the compiler > | gives you. > Wrong. We did. Then you were wrong. I could have spent time explaining them when they make sense and why they don't in their usecases. If you did, well, then you really need to know better what you do because you seem to me pretty confused yourself, and I feel pity for you. > Well no, if you're cross compiling you should be using an entirely > separate configuration setup. Same arch, slightly different setup, I find simpler to change CFLAGS. > Basic software engineering principles. Or basic English, if you prefer. Sorry I'm in the "Software engineering does not make real world usable" club. And find such terms opinable, subjective and vague. > CFLAGS != ASFLAGS. Point being? The idea would be that by default it passes the current GCC's -march. > Well yes. There're all sorts of things wrong with this proposal, and > some of them are more obvious than others. Still, it makes sense to > start with the easy ones and see whether they'll suffice before moving > onto more complex objections... No it does not, as one would expect the big problems being hashed out first and then fine grained. But maybe I'm just a different kind of practical person than you are. Or you are not a practical person at all and just think of software engineering and theories and "this should work this way even if there is no real world way to make use of it" oh wait... -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpQmaDqlzqSo.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
Diego 'Flameeyes' Pettenò wrote: >> * a large part of the justification is based upon a misunderstanding of >> how cross compilation should be done. The correct way around this >> problem was already posted to the thread by solar. > No I'm not misunderstand how cross compilation should be done with a package > manager. I'm saying that this will anyway give a hand to that. What I was > referring to mostly comes down to the fact that, if I want to build a bin > package for amd64 nocona arch, right now I am not guaranteed that setting > CFLAGS to -march=nocona will produce the right result. Using a proper profile and not hardwire useflags to use amd64 is a solution too. > No it is not. Want to get the news? People at binutils were discussing about > adding -march support to gas, so that it would refuse to build asm sources > that contains instructions not supported by the -march value passed. That works this way already on ppc but... > So using -march=i586 with mmx useflag wouldn't work anymore. ...I don't see why not since gas is supposed to accepth -m* flags related (see man as) > > For what concerns me, I brought the idea, I find the single regression > acceptable, I find it a proper usage of $CFLAGS variable, I find the > internals guaranteed enough to work. My work is done here, I leave to anybody > else to say what they think, as it seems I'm not the only one thinking this > is a good idea. > Amen but isn't the only way and as I told you already I'd rather have stuff properly set in profiles specific even if I like the idea of being able to check for compiler support. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Fri, 7 Jul 2006 01:39:05 +0200 Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote: | > * it's relying upon non-guaranteed GCC internals. | | Not that internals, that part is guaranteed to work, or we cannot | consider guaranteed __PIC__ either, and we rely on that heavily. With __PIC__ there's not much choice. Here there is. | > * it's relying upon GCC knowing the state of the underlying system, | > which fails at least for VIS. | | Define "state of underlying system" because that is not a complete | definition. This is not a state machine we're talking about, and | we're not in science class. In the VIS case, there are plenty of situations where GCC will think that the underlying system doesn't do VIS (because that's the only way of stopping it from producing broken code), but where hand-crafted VIS code is fine and desirable. | > * it's forcing users to use insane CFLAGS hacks, which we've spent | > years telling them not to do and for good reason, to get back to | > previous behaviour. | | No, we never spent years telling them not to use your so-called | "CFLAGS hacks" that are rather a proper usage of what the compiler | gives you. Wrong. We did. | > * a large part of the justification is based upon a | > misunderstanding of how cross compilation should be done. The | > correct way around this problem was already posted to the thread by | > solar. | | No I'm not misunderstand how cross compilation should be done with a | package manager. I'm saying that this will anyway give a hand to | that. What I was referring to mostly comes down to the fact that, if | I want to build a bin package for amd64 nocona arch, right now I am | not guaranteed that setting CFLAGS to -march=nocona will produce the | right result. Well no, if you're cross compiling you should be using an entirely separate configuration setup. | > * it's removing transparency and simplicity and replacing them with | > obfuscation and complexity. | | It's removing green and yellow and adding black and white. | Your words are useless unless you explain them. Basic software engineering principles. Or basic English, if you prefer. Transparency: what is happening is obvious. That is to say, the CFLAGS variable affects flags that are passed when compiling C, and the USE_THESE_FANCY_X86_EXTRAS variable affects the fancy x86 extras that are used in cases where there are optional fancy x86 extras. Simplicity: what is happening is happening without unnecessary extras or complication. Obfuscation: what is happening is not obvious, and is being hidden. For example, the CFLAGS variable doesn't actually just alter CFLAGS, it also triggers some unrelated code that turns on other unrelated features. It's like having a function called display_person(person) that as a side effect also deducts five percent of that person's salary. Complexity: what is happening takes many steps and relies upon many different systems, assumptions or code paths. Like, say, a scary hack of a function where previously there was just a variable. | > * it's taking a variable with a well defined purpose and abusing it | > for something unrelated. | | No it is not. Want to get the news? People at binutils were | discussing about adding -march support to gas, so that it would | refuse to build asm sources that contains instructions not supported | by the -march value passed. So using -march=i586 with mmx useflag | wouldn't work anymore. CFLAGS != ASFLAGS. | > Will that lot do or would you like some more? | | You have the innate ability to find more arguments when the ones you | brought on are not accepted. Well yes. There're all sorts of things wrong with this proposal, and some of them are more obvious than others. Still, it makes sense to start with the easy ones and see whether they'll suffice before moving onto more complex objections... | I find it a proper usage of $CFLAGS variable Ouch. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thursday 06 July 2006 16:14, Harald van Dijk wrote: > Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches > don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported > compiler in Gentoo. you're just griping because i forced ssp/pie regardless of USE=vanilla ... since gcc-4.0 and below are on the way out, i have no problem changing this behavior besides, since both of these technologies are in mainline gcc now, i really dont see how you can continue to gripe with gcc-4.1.1+ -mike pgpIF6VkHyicH.pgp Description: PGP signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thursday 06 July 2006 15:55, Harald van Dijk wrote: > I don't have a lot of trust in Gentoo's patches, as they have resulted > in completely and utterly unusable ld, and (minor) data loss due to a > miscompilation by Gentoo's gcc, in the past. historically i'd agree with you but i'm pretty confident that this has gotten a ton better with 3.3.6 / 3.4.6 / 4.0.3 / 4.1.1 > Also, being able to check > whether your own software compiles with a GNU toolchain is to me a good > thing. USE=vanilla -mike pgpq09DVaZYre.pgp Description: PGP signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thursday 06 July 2006 15:56, Ciaran McCreesh wrote: > Selective and partial backporting of patches that leads to the C++ > standard library code getting broken? that patch was picked up by more than just Gentoo and then just as summarily punted -mike pgpmw8k1Bgvxk.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 01:16, Ciaran McCreesh wrote: > Please try to keep this technical, even if your co-developers can't... You started this. > * it's relying upon non-guaranteed GCC internals. Not that internals, that part is guaranteed to work, or we cannot consider guaranteed __PIC__ either, and we rely on that heavily. > * it's relying upon GCC knowing the state of the underlying system, > which fails at least for VIS. Define "state of underlying system" because that is not a complete definition. This is not a state machine we're talking about, and we're not in science class. > * it's removing the ability to get access to the data at the metadata > phase, leading to what you yourself called a "regression". Yes, a little regression. That's what pro&cons consideration are needed for after all. > * it's forcing users to use insane CFLAGS hacks, which we've spent years > telling them not to do and for good reason, to get back to previous > behaviour. No, we never spent years telling them not to use your so-called "CFLAGS hacks" that are rather a proper usage of what the compiler gives you. I would _not_ ask someone why he's using -mno-mmx for instance, but I _will_ tell someone using -march=athlon64 -mmmx -msse -msse2 -m3dnow -m3dnowex that he's not doing anything useful. Kinda like I do to people who uses -Wl,--enable-new-dtags [1] > * a large part of the justification is based upon a misunderstanding of > how cross compilation should be done. The correct way around this > problem was already posted to the thread by solar. No I'm not misunderstand how cross compilation should be done with a package manager. I'm saying that this will anyway give a hand to that. What I was referring to mostly comes down to the fact that, if I want to build a bin package for amd64 nocona arch, right now I am not guaranteed that setting CFLAGS to -march=nocona will produce the right result. > * it's removing transparency and simplicity and replacing them with > obfuscation and complexity. It's removing green and yellow and adding black and white. Your words are useless unless you explain them. > * it's taking a variable with a well defined purpose and abusing it for > something unrelated. No it is not. Want to get the news? People at binutils were discussing about adding -march support to gas, so that it would refuse to build asm sources that contains instructions not supported by the -march value passed. So using -march=i586 with mmx useflag wouldn't work anymore. It does make sense to them and it does to me too. > Will that lot do or would you like some more? You have the innate ability to find more arguments when the ones you brought on are not accepted. For what concerns me, I brought the idea, I find the single regression acceptable, I find it a proper usage of $CFLAGS variable, I find the internals guaranteed enough to work. My work is done here, I leave to anybody else to say what they think, as it seems I'm not the only one thinking this is a good idea. [1] http://farragut.flameeyes.is-a-geek.org/articles/2006/06/22/nonsensical-hacks-why-i-find-kdenewldflags-stupid -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpyJw1w2B75S.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On 7/6/06, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote: Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags present in the tree, almost never used to get new dependencies, but usually used to supply econf switches. Hoping the S/N ratio here hasn't gotten too high... IMO the main purpose of USE flags should be econf switches. Pulling in dependancies should be viewed as more of a side-effect, even if a common one. If the user wants "./configure ... --enable-gtk", then they need gtk on their box. Similarly, the mmx,sse,3dnow,etc useflags should be there for econf switches, not additions to CFLAGS. If the autoconf script has an --enable-mmx option, then the proper way to control that is through a useflag. I don't object to ebuilds adding CFLAGS/CXXFLAGS based on the result of your has_cpuset (for example, --fpmath= could be useful), but I don't believe has_cpuset should be used to set econf switches. And users should absolutely not have to muck with bashrc to disable this. Add a FEATURE, or something, to enable/disable it if necessary. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
i'll be keeping track of nominations here: http://dev.gentoo.org/~vapier/council-2006-nominees.html lemme know if i missed one of you suckers yes it's very basic, when i get a min i'll guide-xml it :P -mike pgphwOfWz2WSL.pgp Description: PGP signature
[gentoo-dev] Re: Portage: missing pieces
Dont "snip". The relevant part comes *after* the "blocks" lines. Aah. I get it. Thanks. Sorry for the noise. > www-client/seamonkey (is blocking www-client/mozilla-1.7.13) Also, you are mis-interpreting the "blocks" lines. The correct reading of "X (is blocking Y)" is that you have (or should have) X installed, and now portage wants to install Y instead. Usually this is because Y supercedes the functionality that used to be provided by X, and in almost all cases, the right thing to do is to unmerge X and merge Y. Evolution depends on Mozilla and Mono depends on SeaMonkey. Mono is the "newer" (actively developed... sort of) component, also, from what I've heard, SeaMonkey is based on a vastly newer version of Gecko. So I'm not sure how that fits with the above. Anyway, I tried unmerging SeaMonkey and merging Mozilla, which went fine. Doesn't help any with the blocker status, though. So I'm stuck here. Is it impossible to have Mono and Evolution installed at the same time? (Same story with OpenSSH and pam-login. OpenSSH wants shadow, and pam-login refuses to merge alongside shadow. I want both pam-login and OpenSSH, but seems like I'll have to choose, right?) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] USE_EXPAND_HIDDEN: why make.globals?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
> Is there any particular reason USE_EXPAND_HIDDEN needs to be in
> make.globals, as opposed to in base/make.defaults alongside USE_EXPAND?
> Seems to me it'd make more sense were the two kept together...
Given the support that's currently available in portage, that seems like a good
move to my. However, I've been thinking about proposing the addition of
support for things like $PORTDIR/profiles/{make.defaults,bashrc,package.use} as
part of a "repo level" profile. These would be a logical extension of the
support that already exists for $PORTDIR/profiles/package.mask. But anyway,
base/make.defaults makes sense for now.
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.4 (GNU/Linux)
iD8DBQFErZxp/ejvha5XGaMRAvw4AKCiNolBORuKxOhptk6THRqG8PrmkwCgwCVt
hjybF1i7x/ymSkKx7QbxyEg=
=kziC
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On Wednesday 05 July 2006 12:28, Alexandre Buisse wrote: > Please correct me if I am wrong, but there is no point in nominating > people multiple times, right? *shrug* gives a good indication of who you think is competent and/or who has the best abs (seemant does btw) -mike pgpwmfns69sHU.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 23:45:21 +0200 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: | On Thursday 06 July 2006 23:23, Ciaran McCreesh wrote: | > No, Diego. The argument is that you're coming up with a horrible and | > unnecessary hack where there are far cleaner alternatives, and that | > you're blindly sticking to it and trying to throw off any | > objections by devious means because you don't want to scrap said | > hack after all the misguided effort you've spent on it. However, | > since you seem to be incapable of admitting the gaping flaws in | > your own work, I'm asking for someone else to point this out to you | > in a formal manner rather than watch this thread go on for even | > longer. | | Wait, isn't that what _you_ usually do? Like climbing up on mirrors | when you misunderstood something and blamed someone for an error that | was never made, trying to find another glitch in the procedure to | back it up? Please try to keep this technical, even if your co-developers can't... | I'm entirely ready to scrap what I have here if I find _valid reasons | to_. What's wrong with the ones you've been given so far? I'll summarise the ones I consider important: * it's relying upon non-guaranteed GCC internals. * it's relying upon GCC knowing the state of the underlying system, which fails at least for VIS. * it's removing the ability to get access to the data at the metadata phase, leading to what you yourself called a "regression". * it's forcing users to use insane CFLAGS hacks, which we've spent years telling them not to do and for good reason, to get back to previous behaviour. * a large part of the justification is based upon a misunderstanding of how cross compilation should be done. The correct way around this problem was already posted to the thread by solar. * it's removing transparency and simplicity and replacing them with obfuscation and complexity. * it's taking a variable with a well defined purpose and abusing it for something unrelated. Will that lot do or would you like some more? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Tue, 4 Jul 2006 15:04:38 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > i guess i'll start off some mass nominations of random people off the > top of my head who i think would do a good job ... there's a bunch > more people i think would do a good job, but i'm going to cut my list > short as it's already ridiculously long ... Thanks for the nomination! :) However I don't feel that I currently have the time to put towards this that it needs. Here is hoping towards next year :) Cheers, -- Jason Wever Gentoo/Sparc Team Co-Lead signature.asc Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
Jory A. Pratt wrote: > Ciaran McCreesh wrote: >>> On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson <[EMAIL PROTECTED]> >>> wrote: >>> | Or instead of throwing a hissy fit yourself about diego not agreeing >>> | with you..I don't know you could go and show the way that you feel it >>> | should be done and show the technical merit. Ciaran I will give you >>> | that you are a capable programmer, and had valid arguments in this >>> | thread. However, when interacting with people and proving points on >>> | merits you seem to go out of your way to not prove anything and throw >>> | examples out there without really backing them up. >>> >>> No, I go out of my way to avoid posting hundred page essays explaining >>> things that people already know. If there's really anyone reading this >>> discussion who doesn't understand any of the points being discussed, >>> they're more than welcome to ask for clarification. However, given how >>> basic an issue this is, is it really worth wasting everyone's time with >>> huge explanations of what CFLAGS is? >>> >>> Come on, do you really think anyone will benefit from another >>> http://dev.gentoo.org/~blubb/duncan.pdf ? >>> > > Stephen Bennett wrote: >>> On Thu, 06 Jul 2006 14:31:56 -0700 >>> Joshua Jackson <[EMAIL PROTECTED]> wrote: >>> Or instead of throwing a hissy fit yourself about diego not agreeing with you..I don't know you could go and show the way that you feel it should be done and show the technical merit. >>> He already has done. > > > After reading this thread I can see this is just another one of ciaran's > b.s games that Stephen happens to back. My question is just how far up > ciaran's ass does stephen go. I am begining to think we will never get > to the end if ciaran and his bullshit around gentoo, nor will we ever > get rid of stephen's bullshit around gentoo. But the project continues > to allow such non-sence and wonders why devs are still walking away. > > > I'm not sticking up for Ciaran, he already made his bed and now he's laying in it. I'm sticking up for spb who is a damn good dev and doesn't deserve this kind of bullshit dumped on him. spb works his ass off for this project and is */ALWAYS/* very professional. Just look at the past few threads that he has started where he totally changed his approach based on feedback from everyone (hell, look at ANY technical discussion that spb has ever had regarding Gentoo - not just the last few mail threads). He was professional, listened attentively and made changes based on the feedback that satisfied everyone involved while still solving the problem at hand. Sounds like a damn good developer to me. One I would like to see more of in Gentoo. spb != ciarnm Just my two cents for what it's worth. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
Diego 'Flameeyes' Pettenò wrote: [summary:provide a way to enable simd features by extracting them from the ones supported by the cflags selected and the compiler] Pros: - automagic : you just carefully select your cflags and your apps will have all the simd goodness you may dream/want/expect. - less useflags around - simpler life when building stages (given we gut cpuinfo checks in configures) Cons: - assumes gcc - per ebuild cflags feat isn't ready yet - makes less simple to have certain corner case Alternatives: - as PPC we provide a default cflags & use tuned per certain cpu families using profiles, amd64 could provide a nocona profile that bans 3dnow* useflags. - have simdflags as use_expand to keep them on a single place and improve the description - as before but provide an eclass that uses flameeyes infrastructure to warn about possible mismatch between what the cflags could do and what you expect to obtain eg: -mcpu=nocona use 3dnow would issue a warning and disable it - as the one before again but with a var to decide if follow the use or the gcc check. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 06 Jul 2006 17:09:22 -0500 "Jory A. Pratt" <[EMAIL PROTECTED]> wrote: > Leaving aside the incoherent ad-hominem attack, could you please point out where the bullshit is? If you were referring to my post, I suggest you re-read Ciaran's first mail to this thread. He outlined at least two possible alternatives, but everyone seems to have ignored this. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] init.d problem
On Thursday 06 July 2006 15:27, Albert Hopkins wrote: > On Tue, 2006-07-04 at 18:58 -0400, Mike Frysinger wrote: > > On Tuesday 04 July 2006 18:43, Enrico Weigelt wrote: > > > We should think about mechanisms to check if the service is > > > actually running. This could also be used for frequently service > > > checks and notification. > > > > there is no fool proof way to do this > > Has anyone considered daemontools? It does this kind of stuff very > well. you're "fixing" the issue by replacing sysvinit/baselayout with daemontools some people may want to do that but really i dont see how that's generally relevant to this discussion -mike pgpNOzInupUbJ.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson <[EMAIL PROTECTED]> > wrote: > | Or instead of throwing a hissy fit yourself about diego not agreeing > | with you..I don't know you could go and show the way that you feel it > | should be done and show the technical merit. Ciaran I will give you > | that you are a capable programmer, and had valid arguments in this > | thread. However, when interacting with people and proving points on > | merits you seem to go out of your way to not prove anything and throw > | examples out there without really backing them up. > > No, I go out of my way to avoid posting hundred page essays explaining > things that people already know. If there's really anyone reading this > discussion who doesn't understand any of the points being discussed, > they're more than welcome to ask for clarification. However, given how > basic an issue this is, is it really worth wasting everyone's time with > huge explanations of what CFLAGS is? > > Come on, do you really think anyone will benefit from another > http://dev.gentoo.org/~blubb/duncan.pdf ? > Stephen Bennett wrote: > On Thu, 06 Jul 2006 14:31:56 -0700 > Joshua Jackson <[EMAIL PROTECTED]> wrote: > >> Or instead of throwing a hissy fit yourself about diego not agreeing >> with you..I don't know you could go and show the way that you feel it >> should be done and show the technical merit. > > He already has done. After reading this thread I can see this is just another one of ciaran's b.s games that Stephen happens to back. My question is just how far up ciaran's ass does stephen go. I am begining to think we will never get to the end if ciaran and his bullshit around gentoo, nor will we ever get rid of stephen's bullshit around gentoo. But the project continues to allow such non-sence and wonders why devs are still walking away. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErYoRo9V4dnAHxYwRAiq7AJ4+kLNig3h0Ra8k9CuLJynDFBuC+QCgiq/W BFKmn9FzOXFhWgBt8rSbUdo= =wTC0 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing einfo with elog
On Thu, 6 Jul 2006 23:51:09 +0200 Marius Mauch <[EMAIL PROTECTED]> wrote: > A few minutes ago I committed the attached patch to > base/profile.bashrc so this is no longer an issue (for 2.0 users elog > is merely an alias to einfo). *sigh*, gotta get rid of this attachment-eating gremlin someday. Anyway, patch is available at dev.gentoo.org/~genone/temp/elog-compat-hack.diff (not that it is actually important). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
[gentoo-dev] Replacing einfo with elog
For the impatient reader:
Ebuilds should stop using einfo() for important messages and use elog()
instead.
Rationale:
I assume most of you are already aware of the new elog framework in
portage-2.1 for handling ebuild messages (like sending them by
mail/syslog or just storing them for later review).
This works very well, except that currently if you enable einfo logging
the user will be swamped with many status messages ("updating
foo", "removing bar") that might be interesting when you watch the build
output but are rather useless once the build is done.
To avoid this information overflow einfo messages aren't logged in the
default portage config, but that means that right now users will only
see ewarn and eerror messages and miss some einfos that might be
important.
To fix this problem a new function elog() was added in portage-2.1 to
close the gap between einfo and ewarn. THe reason this wasn't advertised
until now is that it couldn't be used in the tree as the function didn't
exist for people still on portage-2.0. A few minutes ago I committed the
attached patch to base/profile.bashrc so this is no longer an issue
(for 2.0 users elog is merely an alias to einfo). So from now on please
use elog() for any messages the user should read and use einfo() only
for status/progress messages that have no use once the build is
completed.
I'll get the relevant docs updated in the next days.
Marius
--
Public Key at http://www.genone.de/info/gpg-key.pub
In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson <[EMAIL PROTECTED]> wrote: | Or instead of throwing a hissy fit yourself about diego not agreeing | with you..I don't know you could go and show the way that you feel it | should be done and show the technical merit. Ciaran I will give you | that you are a capable programmer, and had valid arguments in this | thread. However, when interacting with people and proving points on | merits you seem to go out of your way to not prove anything and throw | examples out there without really backing them up. No, I go out of my way to avoid posting hundred page essays explaining things that people already know. If there's really anyone reading this discussion who doesn't understand any of the points being discussed, they're more than welcome to ask for clarification. However, given how basic an issue this is, is it really worth wasting everyone's time with huge explanations of what CFLAGS is? Come on, do you really think anyone will benefit from another http://dev.gentoo.org/~blubb/duncan.pdf ? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 23:23, Ciaran McCreesh wrote: > No, Diego. The argument is that you're coming up with a horrible and > unnecessary hack where there are far cleaner alternatives, and that > you're blindly sticking to it and trying to throw off any objections by > devious means because you don't want to scrap said hack after all the > misguided effort you've spent on it. However, since you seem to be > incapable of admitting the gaping flaws in your own work, I'm asking for > someone else to point this out to you in a formal manner rather than > watch this thread go on for even longer. Wait, isn't that what _you_ usually do? Like climbing up on mirrors when you misunderstood something and blamed someone for an error that was never made, trying to find another glitch in the procedure to back it up? Yeah that really sounds like you more than me. I'm entirely ready to scrap what I have here if I find _valid reasons to_. All you seem to be able to say is that you don't like this, you point to a control that users have not much for a valid reason than for the simple fact that the useflag was a good way to allow user to choose what it had without forcing it to use support that was not supported on their system. A solution that worked, but that is not the only one, and that I wouldn't consider a great choice that users really need to be able to use Gentoo. The most interesting point shown up until now is the one about non-gcc compatibility, that I actually thought about for a while, but I thought -dM was unix standard option, Harald got me there, and I'll be checking for something in ICC. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpx6QSrOFiRm.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 06 Jul 2006 14:31:56 -0700 Joshua Jackson <[EMAIL PROTECTED]> wrote: > Or instead of throwing a hissy fit yourself about diego not agreeing > with you..I don't know you could go and show the way that you feel it > should be done and show the technical merit. He already has done. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] USE_EXPAND_HIDDEN: why make.globals?
Is there any particular reason USE_EXPAND_HIDDEN needs to be in make.globals, as opposed to in base/make.defaults alongside USE_EXPAND? Seems to me it'd make more sense were the two kept together... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Or instead of throwing a hissy fit yourself about diego not agreeing with you..I don't know you could go and show the way that you feel it should be done and show the technical merit. Ciaran I will give you that you are a capable programmer, and had valid arguments in this thread. However, when interacting with people and proving points on merits you seem to go out of your way to not prove anything and throw examples out there without really backing them up. > > No, Diego. The argument is that you're coming up with a horrible > and unnecessary hack where there are far cleaner alternatives, and > that you're blindly sticking to it and trying to throw off any > objections by devious means because you don't want to scrap said > hack after all the misguided effort you've spent on it. However, > since you seem to be incapable of admitting the gaping flaws in > your own work, I'm asking for someone else to point this out to you > in a formal manner rather than watch this thread go on for even > longer. > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErYFLSENan+PfizARAjzzAJwIue9UDtwsANxaaqqnVJVr0jTz6ACglAL6 cO7O0Pw+CGDfFlVdY7z1N3o= =6G6V -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 23:12:51 +0200 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: | On Thursday 06 July 2006 22:58, Ciaran McCreesh wrote: | > You're not going to give in gracefully, huh? Ok, I'd like to ask the | > council to declare that abusing CFLAGS in the manner proposed in | > this thread is a very bad idea. | | If you finished the proper arguments, the next one will be that it's | all a cabal of infra against you, I suppose. No, Diego. The argument is that you're coming up with a horrible and unnecessary hack where there are far cleaner alternatives, and that you're blindly sticking to it and trying to throw off any objections by devious means because you don't want to scrap said hack after all the misguided effort you've spent on it. However, since you seem to be incapable of admitting the gaping flaws in your own work, I'm asking for someone else to point this out to you in a formal manner rather than watch this thread go on for even longer. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 22:58, Ciaran McCreesh wrote: > You're not going to give in gracefully, huh? Ok, I'd like to ask the > council to declare that abusing CFLAGS in the manner proposed in this > thread is a very bad idea. If you finished the proper arguments, the next one will be that it's all a cabal of infra against you, I suppose. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpjBAukAFhDn.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 23:10, Kevin F. Quinn wrote: > There's -march=pentium-mmx for this. I forgot about it, thanks for pointing it out :) -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpzOhSWFVsLH.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 22:13:11 +0200 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: > Note: -march=i586 -mmmx for Pentium (classic) MMX is a good idea most > of the times, as it's not an i686 but at the same time it has MMX > support. There's -march=pentium-mmx for this. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 22:46:31 +0200 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: | On Thursday 06 July 2006 22:24, Ciaran McCreesh wrote: | > Well, if you're playing that game, I'd suggest that anybody wanting | > to make proposals on this issue should know what CFLAGS is and | > understand how it is nothing other than a set of flags that are | > passed to the compiler when compiling a C program, and then | > evaluate the impact of subverting such a variable for nefarious | > purposes. | | And I suggest that anybody willing to comment on user-side of things | would know what an user is and understand how users feel about | issues, instead of going on and on and on commenting without having a | clue. You're not going to give in gracefully, huh? Ok, I'd like to ask the council to declare that abusing CFLAGS in the manner proposed in this thread is a very bad idea. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: GPL and Source code providing
On Thu, 2006-07-06 at 15:14 -0400, Michael Cummings wrote:
> Probably too off the wall and simpleton for the "problem" - but what if
> the install docs included something like:
>
> "
> To obtain the sources for your new install, please use:
>
> emerge -fDN world
>
> to download all of the sources used to build your stage3 install.
> "
>
> (the presumption being after the unrolling of stage3, they would have to
> get the sources anyway to proceed forward, so this would fill the
> initial gap...or am I missing something more critical?)
Well, it would need to be -efDN, but that doesn't take into account what
happens when someone uses a tarball from 2 releases ago that is still on
our mirrors, but the packages haven't been in the tree (and therefore
not on our mirrors) for months. For the most part, it would work,
provided upstream kept copies of their older sources, but there would
still be source lost, like patches in ${FILESDIR}. This only works so
long as we have everything either in the tree or on our infrastructure.
A burned DVD, however, will always have the old stuff there, no matter
what happens in the tree.
It really is the simplest method for us.
--
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 22:24, Ciaran McCreesh wrote: > Well, if you're playing that game, I'd suggest that anybody wanting to > make proposals on this issue should know what CFLAGS is and understand > how it is nothing other than a set of flags that are passed to the > compiler when compiling a C program, and then evaluate the impact of > subverting such a variable for nefarious purposes. And I suggest that anybody willing to comment on user-side of things would know what an user is and understand how users feel about issues, instead of going on and on and on commenting without having a clue. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpZvC5MwKfS1.pgp Description: PGP signature
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Tue, 4 Jul 2006 15:04:38 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > some other peeps: > Kugelfang / Ramereth / Mr_Bones / spb / plasmaroo / Weeve / `Kumba / > jaervosz / KingTaco / Flameeyes / dostrow / dsd / kito / exg Thanks, accepted. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 22:13:11 +0200 "Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: | So I would suggest anybody wanting to comment on these issue to know | the difference of using mmx in useflag and -mmmx in CFLAGS at the | moment. And then evaluate the change in behaviour. Well, if you're playing that game, I'd suggest that anybody wanting to make proposals on this issue should know what CFLAGS is and understand how it is nothing other than a set of flags that are passed to the compiler when compiling a C program, and then evaluate the impact of subverting such a variable for nefarious purposes. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, 6 Jul 2006 20:56:31 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > Selective and partial backporting of patches that leads to the C++ > standard library code getting broken? Obviously not an issue. Noone uses C++ anyway. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 22:02, Curtis Napier wrote: > Every developer who has ever commented on one of these threads has > always agreed with that. Put it in USE not CLFAGS. Well it's not totally right. Putting them in CFLAGS, when using -march, is redundant, pure and simple. -march=athlon64 -msse -msse2 -mmmx -m3dnow -m3dnowex would be equivalent of -march=athlon64 If you have a new Athlon64 that supports SSE3, using -march=athlon64 -msse3 is not only legit, but also (in my opinion at least) suggested. GCC can improve heavily if it knows what it has to do. The problem is that people think that using -march=pentium3 -mmmx will bring them more acceleration, while this isn't true. So I would suggest anybody wanting to comment on these issue to know the difference of using mmx in useflag and -mmmx in CFLAGS at the moment. And then evaluate the change in behaviour. Note: -march=i586 -mmmx for Pentium (classic) MMX is a good idea most of the times, as it's not an i686 but at the same time it has MMX support. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgppXtMqRbnIf.pgp Description: PGP signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, Jul 06, 2006 at 04:03:26PM -0400, Stephen P. Becker wrote: > Harald van Dijk wrote: > >On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote: > >>On Thu, 6 Jul 2006 21:06:18 +0200 > >>Harald van Dijk <[EMAIL PROTECTED]> wrote: > >> > >>>The GNU toolchain is not supported by Gentoo, and in fact gets > >>>actively broken with unsupported command-line options. Only the GNU > >>>toolchain as modified by Gentoo's toolchain guys is supported, > >>>unfortunately. > >>What exactly is it about the toolchain supplied with Gentoo that causes > >>you problems? > > > >I don't have a lot of trust in Gentoo's patches, as they have resulted > >in completely and utterly unusable ld, and (minor) data loss due to a > >miscompilation by Gentoo's gcc, in the past. Also, being able to check > >whether your own software compiles with a GNU toolchain is to me a good > >thing. > > Isn't this why gcc et al support the "vanilla" USE flag? Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
Harald van Dijk wrote: On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote: On Thu, 6 Jul 2006 21:06:18 +0200 Harald van Dijk <[EMAIL PROTECTED]> wrote: The GNU toolchain is not supported by Gentoo, and in fact gets actively broken with unsupported command-line options. Only the GNU toolchain as modified by Gentoo's toolchain guys is supported, unfortunately. What exactly is it about the toolchain supplied with Gentoo that causes you problems? I don't have a lot of trust in Gentoo's patches, as they have resulted in completely and utterly unusable ld, and (minor) data loss due to a miscompilation by Gentoo's gcc, in the past. Also, being able to check whether your own software compiles with a GNU toolchain is to me a good thing. Isn't this why gcc et al support the "vanilla" USE flag? -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Ciaran McCreesh wrote: > On Thu, 6 Jul 2006 20:42:27 +0200 "Diego 'Flameeyes' Pettenò" > > | > Setting CFLAGS and praying is not asking for something. Setting a > | > MY_X86_CPU_DOES_THIS_MKAY variable is asking for something. > | > | And if you know what your CPU does, is it that difficult to tell the > | compiler to use them? > > Yes. That -msse -mnosse2 stuff is a nasty hack, especially when one > remembers that for years we've been screaming at users for doing just > that. > I could find a million threads in the forums supporting what Ciaran is saying here. We have been told over and over and over until my head feels bashed in that MMX/SSE, etc... are NOT TO BE PUT IN CFLAGS!! THAT IS WHAT USE FLAGS ARE FOR Every developer who has ever commented on one of these threads has always agreed with that. Put it in USE not CLFAGS. To change this behavior now after all this time would be crazy IMHO. signature.asc Description: OpenPGP digital signature
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, 6 Jul 2006 21:42:20 +0200 "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: | On Thu, 6 Jul 2006 21:06:18 +0200 | Harald van Dijk <[EMAIL PROTECTED]> wrote: | > The GNU toolchain is not supported by Gentoo, and in fact gets | > actively broken with unsupported command-line options. Only the GNU | > toolchain as modified by Gentoo's toolchain guys is supported, | > unfortunately. | | What exactly is it about the toolchain supplied with Gentoo that | causes you problems? Selective and partial backporting of patches that leads to the C++ standard library code getting broken? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, Jul 06, 2006 at 09:42:20PM +0200, Kevin F. Quinn wrote: > On Thu, 6 Jul 2006 21:06:18 +0200 > Harald van Dijk <[EMAIL PROTECTED]> wrote: > > > The GNU toolchain is not supported by Gentoo, and in fact gets > > actively broken with unsupported command-line options. Only the GNU > > toolchain as modified by Gentoo's toolchain guys is supported, > > unfortunately. > > What exactly is it about the toolchain supplied with Gentoo that causes > you problems? I don't have a lot of trust in Gentoo's patches, as they have resulted in completely and utterly unusable ld, and (minor) data loss due to a miscompilation by Gentoo's gcc, in the past. Also, being able to check whether your own software compiles with a GNU toolchain is to me a good thing. -- gentoo-dev@gentoo.org mailing list
Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Thu, 6 Jul 2006 21:06:18 +0200 Harald van Dijk <[EMAIL PROTECTED]> wrote: > The GNU toolchain is not supported by Gentoo, and in fact gets > actively broken with unsupported command-line options. Only the GNU > toolchain as modified by Gentoo's toolchain guys is supported, > unfortunately. What exactly is it about the toolchain supplied with Gentoo that causes you problems? -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] init.d problem
On Tue, 2006-07-04 at 18:58 -0400, Mike Frysinger wrote: > On Tuesday 04 July 2006 18:43, Enrico Weigelt wrote: > > We should think about mechanisms to check if the service is > > actually running. This could also be used for frequently service > > checks and notification. > > there is no fool proof way to do this Has anyone considered daemontools? It does this kind of stuff very well. -m -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Thursday 06 July 2006 14:40, Grant Goodyear wrote: > Vapier wrote: [Tue Jul 04 2006, 02:04:38PM CDT] > > > i'd also nominate g2boojum, but i kind of like his current unofficial > > role as honorary council adviser guy ... > > *Grin* I'm rather fond of that role myself, so I cheerfully accept the > non-nomination. (Also, I plan to run for trustee again, which is more > than enough administrative annoyance all by itself.) thanks, i sit comfortably knowing you're manning these positions -mike pgpL9i3snDRYb.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: GPL and Source code providing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: > Not really. There is 0 overhead to *leaving* a source DVD set on the > store indefinitely. It is only the creation that requires work. Once > it is there, it's there. > Probably too off the wall and simpleton for the "problem" - but what if the install docs included something like: " To obtain the sources for your new install, please use: emerge -fDN world to download all of the sources used to build your stage3 install. " (the presumption being after the unrolling of stage3, they would have to get the sources anyway to proceed forward, so this would fill the initial gap...or am I missing something more critical?) - -- - -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E - -o()o-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErWEuq1ztTp5/Ti4RApD4AJwJWWjjsC+VFQu6Ymb0AB73OjSt4gCfR0Cn H4AczL0jjHozbgGlnJf9Ljo= =CS7S -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Thursday 06 July 2006 04:45, Martin Schlemmer wrote: > I would like to refrain from accepting until just before the final > nominees are put out, as currently my life is pretty much in flux. If > possible that is. sure ... you can wait until the 31st to accept ;) -mike pgpAU0QKJ2ClD.pgp Description: PGP signature
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Wednesday 05 July 2006 04:31, Donnie Berkholz wrote: > I really appreciate your bringing my name up. But I want to take a year > to rediscover the reasons I joined Gentoo in the first place and the > things I joined it to do, so I'm going to decline this for now. Maybe > next time around. =) i really hope so -mike pgp2vSwi3x4Ca.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, Jul 06, 2006 at 11:41:26AM -0400, Ned Ludd wrote:
> On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
> > Diego 'Flameeyes' Pettenò wrote:
> > > echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null
> >
> > > Thoughts? Comments?
> >
> > How will you handle non-gcc compilers?
>
> Non gcc compilers have never been supported and probably never will be.
>
> Gentoo uses the GNU Toolchain.
The GNU toolchain is not supported by Gentoo, and in fact gets actively
broken with unsupported command-line options. Only the GNU toolchain as
modified by Gentoo's toolchain guys is supported, unfortunately.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, Jul 06, 2006 at 02:21:43PM +0200, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 06 July 2006 13:58, Donnie Berkholz wrote:
> > Well, there are enough in the tree
> There are ebuilds for non-gcc compilers. There's no support in using them for
> anything like building stuff. Let's think to all the append-flags there are
> in the tree.
`append-flags $(test-flags ...)` can be used instead, if the options are
gcc-specific, and I have done that myself in a case where every
supported GCC version supported the specific option. (-fpermissive was
the one.)
> This is not going to make the support any less working. There's
> no project maintaining support for icc and the like.
When the answer is "make icc not suck" even when it is capable of
compiling mostly any package if the portage tree would not assume gcc,
that's not going to happen. First, alternative compilers must be
accepted (even when not supported) by package maintainers, and only then
might they ever become supported.
> > that you should at least make sure
> > they don't completely break and error out when passing them invalid
> > flags,
> Uhm, If you look at the function itself you can see that I drop the stderr
> output and I just care about the other part. The flags used are the ones set
> by the user with the exclusion of -E -dM that are, afaik, standard unix
> compiler options like -c and -o..
-E is a standard unix compiler option. -dM isn't. What you could do
instead is `$(tc-getCC) ${CFLAGS} -E - >/dev/null 2>&1 < if the compiler does not support those,
> it's unlikely it can actually do anything useful in Gentoo.
> And anyway it cannot "break", it will just report that no extensions are
> available.
That's sane behaviour regardless. :)
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 20:42:27 +0200 "Diego 'Flameeyes' Pettenò"
<[EMAIL PROTECTED]> wrote:
| > Not really. The __MAGIC__ is subject to change whenever any GCC
| > person feels like it.
|
| It's not magic. But if you think that going by that trick you can
| magically turn me in agreeing with you, good luck.
They're a bunch of arbitrary somethings that may or may not be defined
based upon whatever upstream feels like doing to the compiler this
week. It's not like the behaviour of your hello world app, which is
defined by international standards.
| > It also doesn't work in cases where people have one of
| > those nasty corner case CPUs (such as the 4m, which is not an m and
| > not really a 4 either, or the USIV, or the r8k) that's best off
| > with a weird march.
|
| That's what the -m{,no-}{mmx,sse,sse2,sse3,3dnow,3dnowex} flags are
| for.
Which is a horrible hack, and far less elegant than just having a
frickin' variable telling ebuilds what to do.
| > Well that's kinda the point. Since ebuild developers don't have
| > access to every kind of CPU, relying upon the ebuilds getting it
| > right isn't a very good idea.
|
| The MMX code either works or don't. Not much to think about different
| CPUs.
And in cases where the choice is "an SSE routine or an MMX routine or a
C routine"? It's not very likely that all possibilities will get tested
by ebuild devs.
| > Since when was Gentoo about covering up for idiots who can't get
| > their ricing correct at the expense of those who know what they're
| > doing?
|
| Again, I don't see any loss for who knows what he's doing.
Because you carefully snipped it out of your reply. You said yourself
that it's a regression.
| > Sure it's magic. The __DEFINES__ aren't reliable. The GCC people
| > change them around now and again for compatibility with other
| > compilers.
|
| Yeah _some_ of them are unreliable. Not those tho, as they are just
| the same on all the GCC we support. And I doubt that next week GCC
| 4.1.2 changes them around.
Oh, you doubt, do you? Very reassuring.
| > Setting CFLAGS and praying is not asking for something. Setting a
| > MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.
|
| And if you know what your CPU does, is it that difficult to tell the
| compiler to use them?
Yes. That -msse -mnosse2 stuff is a nasty hack, especially when one
remembers that for years we've been screaming at users for doing just
that.
CFLAGS is not a variable that should be used to control things. It has
a specific purpose, which is providing flags to the compiler that
should be used when compiling C programs. You're trying to give it a
new unrelated meaning. This is bad even if it were not for all the
nasty side cases and added complexity.
--
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 20:29, Ciaran McCreesh wrote:
> Incidentally, syncing CFLAGS and CXXFLAGS really isn't a good idea if
> you want your C compiler to work and produce vaguely sane code.
I never said to keep them _identical_
I have a set of common flags (between which I have my arch flags) and a set of
flags for C only and one for C++ only.
Again, it does not add more complexity than there is now to handle some
situations.
> Not really. The __MAGIC__ is subject to change whenever any GCC person
> feels like it.
It's not magic. But if you think that going by that trick you can magically
turn me in agreeing with you, good luck.
> It also doesn't work in cases where people have one of
> those nasty corner case CPUs (such as the 4m, which is not an m and not
> really a 4 either, or the USIV, or the r8k) that's best off with a weird
> march.
That's what the -m{,no-}{mmx,sse,sse2,sse3,3dnow,3dnowex} flags are for.
> Well that's kinda the point. Since ebuild developers don't have access
> to every kind of CPU, relying upon the ebuilds getting it right isn't a
> very good idea.
The MMX code either works or don't. Not much to think about different CPUs.
> Since when was Gentoo about covering up for idiots who can't get their
> ricing correct at the expense of those who know what they're doing?
Again, I don't see any loss for who knows what he's doing.
> Sure it's magic. The __DEFINES__ aren't reliable. The GCC people change
> them around now and again for compatibility with other compilers.
Yeah _some_ of them are unreliable. Not those tho, as they are just the same
on all the GCC we support. And I doubt that next week GCC 4.1.2 changes them
around.
> Setting CFLAGS and praying is not asking for something. Setting a
> MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.
And if you know what your CPU does, is it that difficult to tell the compiler
to use them?
--
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgpp6VcnIQYsT.pgp
Description: PGP signature
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
Vapier wrote: [Tue Jul 04 2006, 02:04:38PM CDT] > i'd also nominate g2boojum, but i kind of like his current unofficial > role as honorary council adviser guy ... *Grin* I'm rather fond of that role myself, so I cheerfully accept the non-nomination. (Also, I plan to run for trustee again, which is more than enough administrative annoyance all by itself.) -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpovh6Vp5JnS.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 20:07:00 +0200 "Diego 'Flameeyes' Pettenò"
<[EMAIL PROTECTED]> wrote:
| On Thursday 06 July 2006 19:51, Ciaran McCreesh wrote:
| > And for a single compile?
|
| I always leave the two of them in sync, even C++ apps might have
| parts building CFLAGS. In case you know you're going to use only C++
| is not difficult to use
|
| CFLAGS=${CXXFLAGS} has_cpuset 3dnow
|
| don't you think?
Ah yes, yet more added complexity that's going to be forgotten and that
will lead to weird breakages.
Incidentally, syncing CFLAGS and CXXFLAGS really isn't a good idea if
you want your C compiler to work and produce vaguely sane code.
| > And your assumption would be wrong. I can assure you that relying
| > upon -march doing anything sensible with __MAGIC__ is entirely
| > unsafe. Go and look at the VIS handling if you want a perfect
| > example.
|
| Okay, maybe VIS handling is broken. But we can rely pretty safely on
| x86, amd64 and PPC gcc to know the table of arches and extensions
| supported. Remember that I asked to talk with SPARC team for VIS just
| because I only know about the other three arches.
Not really. The __MAGIC__ is subject to change whenever any GCC person
feels like it. It also doesn't work in cases where people have one of
those nasty corner case CPUs (such as the 4m, which is not an m and not
really a 4 either, or the USIV, or the r8k) that's best off with a weird
march.
| > No no. Where "regain control" means the user has to screw around
| > with nasty hacks and pray, rather than setting a well defined,
| > specific variable.
|
| Find me a reason to do that, a part for broken MMX code that should
| be disabled on the ebuild itself already.
Well that's kinda the point. Since ebuild developers don't have access
to every kind of CPU, relying upon the ebuilds getting it right isn't a
very good idea.
| > Uh. USE flags are available at DEPEND time.
|
| If you talk about the nasm dependency, then it is rare, most of the
| MMX support is inline in C sources anyway.
'most'?
| > And at the metadata phase?
|
| Should be already transparent or something is strange. nasm is
| simpler to add the dependency for x86, there is really few people not
| enabling mmx already. Yes it is a bit of regression, but for a small
| percentage of users, while there's more safety for many other people.
Since when was Gentoo about covering up for idiots who can't get their
ricing correct at the expense of those who know what they're doing?
| > Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the
| > contrary.
|
| This ain't no magic. The magic is in the _CODE_ that GCC creates, but
| not in the _DEFINES_ that GCC emits.
Sure it's magic. The __DEFINES__ aren't reliable. The GCC people change
them around now and again for compatibility with other compilers.
| > You're trying to guess what the user wants based upon hairy magic,
| No, about their chosen architecture.
|
| > rather than doing what the user says (aren't you always yelling at
| > upstreams for doing that?)
|
| The user asks for athlon64 support? They get athlon64 (mmx, 3dnow,
| 3dnowex, sse, sse2)
| The user asks for G3 support? They get G3 (nothing)
| The user asks for Pentium4 support? They get what they want (mmx,
| sse, sse2, sse3 in case)
Setting CFLAGS and praying is not asking for something. Setting a
MY_X86_CPU_DOES_THIS_MKAY variable is asking for something.
--
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 19:51, Ciaran McCreesh wrote:
> And for a single compile?
I always leave the two of them in sync, even C++ apps might have parts
building CFLAGS. In case you know you're going to use only C++ is not
difficult to use
CFLAGS=${CXXFLAGS} has_cpuset 3dnow
don't you think?
> And your assumption would be wrong. I can assure you that relying upon
> -march doing anything sensible with __MAGIC__ is entirely unsafe. Go
> and look at the VIS handling if you want a perfect example.
Okay, maybe VIS handling is broken. But we can rely pretty safely on x86,
amd64 and PPC gcc to know the table of arches and extensions supported.
Remember that I asked to talk with SPARC team for VIS just because I only
know about the other three arches.
> No no. Where "regain control" means the user has to screw around with
> nasty hacks and pray, rather than setting a well defined, specific
> variable.
Find me a reason to do that, a part for broken MMX code that should be
disabled on the ebuild itself already.
> Uh. USE flags are available at DEPEND time.
If you talk about the nasm dependency, then it is rare, most of the MMX
support is inline in C sources anyway.
> And at the metadata phase?
Should be already transparent or something is strange. nasm is simpler to add
the dependency for x86, there is really few people not enabling mmx already.
Yes it is a bit of regression, but for a small percentage of users, while
there's more safety for many other people.
> Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the contrary.
This ain't no magic. The magic is in the _CODE_ that GCC creates, but not in
the _DEFINES_ that GCC emits.
> You're trying to guess what the user wants based upon hairy magic,
No, about their chosen architecture.
> rather than doing what the user says (aren't you always yelling at
> upstreams for doing that?)
The user asks for athlon64 support? They get athlon64 (mmx, 3dnow, 3dnowex,
sse, sse2)
The user asks for G3 support? They get G3 (nothing)
The user asks for Pentium4 support? They get what they want (mmx, sse, sse2,
sse3 in case)
--
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgpEMEE1Ith5N.pgp
Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 18:43:11 +0200 "Diego 'Flameeyes' Pettenò"
<[EMAIL PROTECTED]> wrote:
| On Thursday 06 July 2006 14:49, Ciaran McCreesh wrote:
| > Well, you're assuming that
| Properly listing, what an arcane science.
Perhaps I should've written a Java + XML app that automatically formats
messages according to what the reader probably wants to see.
| > a) everyone's using a C compiler,
|
| No, I assume that everyone is using a compiler. You cannot have a C++
| compiler without a C compiler. The first person I see that sets
| CXXFLAGS but not CFLAGS I'm personally going to give him the "doesn't
| have a clue" prize.
And for a single compile?
| > b) that gcc has the slightest clue what it's doing,
|
| No, I assume that gcc has a big clue about which capabilities are
| available to the -march switch. I might be assuming that users have a
| clue on what they are doing, but that's an assumption I do have to
| do, or I shouldn't be working on Gentoo but on Debian, which seems
| pretty good at optimising for i386 still.
And your assumption would be wrong. I can assure you that relying upon
-march doing anything sensible with __MAGIC__ is entirely unsafe. Go
and look at the VIS handling if you want a perfect example.
| > c) that the user has no problem using nasty hacks to regain control,
|
| Where "regain control" is "doing something that could have done
| before but made actually no sense to do before. And the bashrc thing
| is not a big nasty hack, works quite well for me.
No no. Where "regain control" means the user has to screw around with
nasty hacks and pray, rather than setting a well defined, specific
variable.
| > d) that this information is only needed at compile time,
|
| Well of course use flags are available at runtime for the packages
| built to know, this is perfectly logic of you.
Uh. USE flags are available at DEPEND time.
| You really was getting out of arguments, don't you?
No, you're just not thinking this through.
| If I have to enable a configure switch I need it only at buildtime.
| If it has to be known at runtime there's the cpuid function!
And at the metadata phase?
| > e) that various gcc internal definitions won't change...
| It's like assuming that gcc will always output the correct hello
| world for
|
| int main() {
| printf("Hello, world!\n");
| return 0;
| }
|
| If it does change those values, it's going to be a killer for way
| more than just Portage.
Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the contrary.
It can and does change with different GCC releases. I know there've been
GCC changes on sparc to those kinds of defines to try to play nice with
certain other compilers...
| > You're adding a lot of complexity, and thus
| > room for very weird breakages, to something that doesn't need it.
|
| You're not exposing any of such breakages, I find it to reduce
| complexity to users that cannot try to enable SSE3 on an Athlon-TBird
| system.
You're trying to guess what the user wants based upon hairy magic,
rather than doing what the user says (aren't you always yelling at
upstreams for doing that?), and all because you aren't aware
of how to cross compile correctly.
Now, please go back to justifying this thing on any merits it may have,
rather than playing the "Go and use Debian!!!! card.
--
Ciaran McCreesh
Mail: ciaran dot mccreesh at blueyonder.co.uk
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] IMPORTANT: bugs performance issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thank you to all of our sponsors and especially GNI for being so gracious and giving to us. Not even a little tiny bit of compiling? A smidge? pretty please with a cherry on top? > > Yay, *plop* !!! (And no, tsunam - no compiling there :P) > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErUohSENan+PfizARAtGqAJ9du+4mdXYqEyjTmn5u4cwMyfWHVQCffhhn LSd4QYOi4AeiJWkYPgDgA5I= =W5ou -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 19:09 +0200, Diego 'Flameeyes' Pettenò wrote: > On Thursday 06 July 2006 18:58, Ned Ludd wrote: > > All together as in across the board? Or simply for the 1 pkg > > in question? > For the package in question of course. Do you think I'm an idiot? Seriously? Well. Sorry but there is very little we can assume these days. Just when you think people know what they are doing along comes some hair brained idea that sound ok on the surface but can cause lots of fun problems. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
Mike Doty wrote: Vote Taco! If elected, I promise to add 2 minutes to nap time every Friday and double juice boxes every third Wednesday of the month. WTF! I want to be a dev if there's juice boxes involved! *runs off to take the ebuild quiz* -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 18:58, Ned Ludd wrote: > All together as in across the board? Or simply for the 1 pkg > in question? For the package in question of course. Do you think I'm an idiot? Seriously? -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpTaMpZzqze8.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
Diego 'Flameeyes' Pettenò wrote: > On Thursday 06 July 2006 17:33, Ned Ludd wrote: >> I tend to agree this might be a cleaner approach vs having to edit & >> redit CFLAGS all over the place. > Really if one has to disable mmx support in one package, it should be > disabled > altogether, in the real world we're all in, mmx useflag is enabled by the > vast majority of our users. > Depending on who wrote the altivec part of a program you may like to disable it since works just on macosx /me still would rather have both systems in place. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Kevin F. Quinn wrote: > Had a rough scan through the tree; there are 73 packages that make > direct use of mmx, sse*, 3dnow or altivec in IUSE (list below), > excluding gcc itself. They also appear in the mythtv-plugin eclass > so presumably some of media-plugins/myth* (11 packages) are also > affected. > > I don't know if altivec is as clearly determined from the target arch; > perhaps the ppc people could chime in. it is > > Clearly most are in media-* categories, so that would be a good place > to start :) > yes lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 18:44 +0200, Diego 'Flameeyes' Pettenò wrote: > On Thursday 06 July 2006 17:33, Ned Ludd wrote: > > I tend to agree this might be a cleaner approach vs having to edit & > > redit CFLAGS all over the place. > Really if one has to disable mmx support in one package, it should be > disabled > altogether, in the real world we're all in, mmx useflag is enabled by the > vast majority of our users. All together as in across the board? Or simply for the 1 pkg in question? I seriously hope you are not suggesting across the board cuz that would make me laugh at you for a good hour solid. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 18:02, Luca Barbato wrote: > - if you care do whatever you want, eg: turn cflags for vector units AND > autovectorized and shut down hand vectorized code (yes it could be dump > if the handmade stuff isn't wrong) In the case you need to shut down the hand vectorised code, it has to be done always, not selected by users. It should be transparent for them, and if the code is wrong, just punt it entirely. Or fix it, your call. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgppcbVBjcpSV.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 17:33, Ned Ludd wrote: > I tend to agree this might be a cleaner approach vs having to edit & > redit CFLAGS all over the place. Really if one has to disable mmx support in one package, it should be disabled altogether, in the real world we're all in, mmx useflag is enabled by the vast majority of our users. -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpiOpxvI3HJS.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 14:49, Ciaran McCreesh wrote:
> Well, you're assuming that
Properly listing, what an arcane science.
> a) everyone's using a C compiler,
No, I assume that everyone is using a compiler. You cannot have a C++ compiler
without a C compiler. The first person I see that sets CXXFLAGS but not
CFLAGS I'm personally going to give him the "doesn't have a clue" prize.
> b) that gcc has the slightest clue what it's doing,
No, I assume that gcc has a big clue about which capabilities are available to
the -march switch. I might be assuming that users have a clue on what they
are doing, but that's an assumption I do have to do, or I shouldn't be
working on Gentoo but on Debian, which seems pretty good at optimising for
i386 still.
> c) that the user has no problem using nasty hacks to regain control,
Where "regain control" is "doing something that could have done before but
made actually no sense to do before. And the bashrc thing is not a big nasty
hack, works quite well for me.
> d) that this information is only needed at compile time,
Well of course use flags are available at runtime for the packages built to
know, this is perfectly logic of you.
You really was getting out of arguments, don't you?
If I have to enable a configure switch I need it only at buildtime. If it has
to be known at runtime there's the cpuid function!
> e) that various gcc internal definitions won't change...
It's like assuming that gcc will always output the correct hello world for
int main() {
printf("Hello, world!\n");
return 0;
}
If it does change those values, it's going to be a killer for way more than
just Portage.
> You're adding a lot of complexity, and thus
> room for very weird breakages, to something that doesn't need it.
You're not exposing any of such breakages, I find it to reduce complexity to
users that cannot try to enable SSE3 on an Athlon-TBird system.
--
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgpBazG9uNTou.pgp
Description: PGP signature
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On Thu, Jul 06, 2006 at 10:02:45AM +0200, Patrick Lauer wrote: > So here's my nominations: > > brix Thanks - but I'm not running for Council. ./Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpouFXEJe89e.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
Had a rough scan through the tree; there are 73 packages that make direct use of mmx, sse*, 3dnow or altivec in IUSE (list below), excluding gcc itself. They also appear in the mythtv-plugin eclass so presumably some of media-plugins/myth* (11 packages) are also affected. I don't know if altivec is as clearly determined from the target arch; perhaps the ppc people could chime in. Clearly most are in media-* categories, so that would be a good place to start :) app-crypt/johntheripper dev-lang/pike dev-lang/squeak dev-libs/DirectFB dev-libs/DirectFB-extra dev-php5/eaccelerator games-emulation/dgen-sdl games-emulation/visualboyadvance games-emulation/xmame games-emulation/xmess games-engines/exult media-gfx/gimp media-gfx/inkscape media-gfx/optipng media-libs/allegro media-libs/flac media-libs/gdk-pixbuf media-libs/imlib2 media-libs/libfame media-libs/libggi media-libs/libmovtar media-libs/libmpeg3 media-libs/libquicktime media-libs/mlt media-libs/sdl-gfx media-libs/smpeg media-libs/speex media-libs/xvid media-plugins/eq-xmms media-plugins/vdr-softdevice media-plugins/xmms-mpg123 media-sound/ardour media-sound/audacious media-sound/fluidsynth media-sound/jack-audio-connection-kit media-sound/mpg123 media-sound/noxmms media-sound/terminatorx media-sound/xmms media-sound/zynaddsubfx media-tv/mythtv media-tv/xawtv media-tv/xdtv media-video/avidemux media-video/cinelerra-cvs media-video/dirac media-video/dxr3player media-video/effectv media-video/fame media-video/ffmpeg media-video/gephex media-video/mjpegtools media-video/mpeg4ip media-video/mplayer media-video/ogle media-video/recmpeg media-video/transcode media-video/vlc media-video/xmovie net-irc/xchat net-irc/xchat-gnome net-misc/asterisk sci-chemistry/gromacs sci-libs/acml sci-libs/fftw x11-base/xorg-x11 x11-libs/evas x11-libs/libast x11-misc/rss-glx x11-terms/eterm x11-themes/polymer x11-wm/afterstep x11-wm/metisse -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
Diego 'Flameeyes' Pettenò wrote: > So, I've been drafting this up in my blog[1], and it is a simple way to > replace the CPU feature useflags. My counterproposal: - keep the useflags - add an eclass with the guessing logic from gcc - add an useflag to let people decide the priority between gcc decisions or useflag decisions. So: - don't have to wait for per package cflags - have the hopefully best results if you don't really care (gcc guess) - if you care do whatever you want, eg: turn cflags for vector units AND autovectorized and shut down hand vectorized code (yes it could be dump if the handmade stuff isn't wrong) Sounds fair or I'm missing something? -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
Mike Frysinger wrote: > i guess i'll start off some mass nominations of random people off the top of > my head who i think would do a good job ... there's a bunch more people i > think would do a good job, but i'm going to cut my list short as it's already > ridiculously long ... > > from current council: > koon / agriffis / azarah / seemant / solar Thanks for the nomination, but I can't accept it. I don't have enough time to devote to Gentoo those days so I can't commit to following all/most discussion subjects for the Council job for another year. Maybe sometime in the future ? There are plenty of good/better candidates out there. I second the nominations for plasmaroo, jaervosz, Kugelfang and Weeve. -- Koon -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Ned Ludd wrote:
> On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
>> Diego 'Flameeyes' Pettenò wrote:
>>> echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null
>>> Thoughts? Comments?
>> How will you handle non-gcc compilers?
>
> Non gcc compilers have never been supported and probably never will be.
Neither has USE=-*, but we don't actively try to break it. =) As long as
this doesn't cause all non-gcc compilers to immediately die, I don't
care if they miss out on auto-mmx or whatever.
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] IMPORTANT: bugs performance issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lance Albertson wrote: > All- > > Just thought I'd update you on some of issue's we've been having with > bugzilla.g.o lately. Yes, its been slow in the last few months, but > today has been even slower than normal. The primary reason being another > large OSS project's database was added to the same server which appeared > to cause a larger load than the OSL had expected. I have notified the > OSL about the issue and they are working on bringing up another server > to handle the load. I don't expect this to be done till tomorrow or the > day after that so please be patient. > > On the plus side, thanks to the generosity of one of our great sponsors, > GNI [1], we should be getting a cluster of blade servers in the next > week or so to help with the on going bugzilla issues. I hope to finally > get this resolved soon as its annoying me as well. > > Please thank GNI for helping us out! They really deserve a lot for > helping us :). > > Thanks- > > [1] http://www.gni.com/ > Thankya! Done. I sent a thank-you to [EMAIL PROTECTED], so hopefully they'll see it. :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFErS/DrsJQqN81j74RAiOHAJwOwwlDzdnqvwN8eJ1BHz5Yg3ILTwCgjNy6 oY9Xtie0+1bilnbe2IE2Y4s= =L3LD -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
Mike Frysinger wrote: On Saturday 01 July 2006 02:46, Mike Frysinger wrote: well it's about that time of the year ... time for nominating people for the next Gentoo Council i guess i'll start off some mass nominations of random people off the top of my head who i think would do a good job ... there's a bunch more people i think would do a good job, but i'm going to cut my list short as it's already ridiculously long ... from current council: koon / agriffis / azarah / seemant / solar some other peeps: Kugelfang / Ramereth / Mr_Bones / spb / plasmaroo / Weeve / `Kumba / jaervosz / KingTaco / Flameeyes / dostrow / dsd / kito / exg i'd also nominate g2boojum, but i kind of like his current unofficial role as honorary council adviser guy ... -mike Vote Taco! If elected, I promise to add 2 minutes to nap time every Friday and double juice boxes every third Wednesday of the month. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
> Diego 'Flameeyes' Pettenò wrote:
> > echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null
>
> > Thoughts? Comments?
>
> How will you handle non-gcc compilers?
Non gcc compilers have never been supported and probably never will be.
Gentoo uses the GNU Toolchain.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 17:09 +0200, Simon Stelling wrote:
> Ciaran McCreesh wrote:
> > You can do it through bashrc. But then, if this is about working around
> > Portage's annoying lack of sane cross compile handling, why not put a
> > little effort into fixing it properly rather than a lot of effort into
> > making the tree more complicated?
>
> Err, I think you're mixing up different things.
> How should portage be
> able to do sane cross compiling if you control the instruction sets
> through use flags which are blocked in profiles the build system is
> using?
That is not the case anymore.. See PORTAGE_CONFIGROOT= and the
attachment as an example which solves this exact problem.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
export PORTDIR=$(portageq envvar PORTDIR)
export ROOT=/dev/shm/blah
export PORTAGE_CONFIGROOT=${ROOT}
PROFILES="$(grep ^[a-z,0-9] ${PORTDIR}/profiles/profiles.desc | awk '{print
$2}' | sort -u)"
mkdir -p ${PORTAGE_CONFIGROOT}/etc/
cd ${PORTAGE_CONFIGROOT}/etc/
for p in ${PROFILES}; do
rm -f make.profile
ln -s ../../../../${PORTDIR}/profiles/${p} make.profile
touch make.conf
ls -ld $(readlink -f make.profile)
emerge --info
done
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 13:19 +0100, Ciaran McCreesh wrote: > On Thu, 6 Jul 2006 12:52:29 +0200 "Diego 'Flameeyes' Pettenò" > <[EMAIL PROTECTED]> wrote: > | Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags > | present in the tree, almost never used to get new dependencies, but > | usually used to supply econf switches. > | > | This works as long as the user enable the flags, but for AMD64 the > | story was, until now, that we simply enabled them when they worked, > | because we had some minimum support available. Unfortunately this > | became a problem with the introduction of nocona, because that is an > | amd64-like system but with no 3dnow. And there is the problem that > | sse3 is supported only in later versions of Athlon64 and so on. > > The other option here... Is to rename the x86 flags to x86_mmx, > x86_3dnow etc, and use amd64_sse3 for amd64 flags, since they're not > really the same as the x86 flags. > > There's probably some USE_EXPAND trickery that can be used here... > CPU_FEATURE_X86="mmx sse" -> cpu_feature_x86_mmx etc might be cleaner? I tend to agree this might be a cleaner approach vs having to edit & redit CFLAGS all over the place. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 06 Jul 2006 17:09:42 +0200 Simon Stelling <[EMAIL PROTECTED]> wrote: | Ciaran McCreesh wrote: | > You can do it through bashrc. But then, if this is about working | > around Portage's annoying lack of sane cross compile handling, why | > not put a little effort into fixing it properly rather than a lot | > of effort into making the tree more complicated? | | Err, I think you're mixing up different things. How should portage be | able to do sane cross compiling if you control the instruction sets | through use flags which are blocked in profiles the build system is | using? That's just it. You shouldn't be using the wrong profile when compiling things. | In fact, moving away from use flags over to the real(TM) | solution is a step towards fixing the issue. Also, it doesn't make | the tree more complicated. It is far more intuitive that supported | instruction sets are used if the user doesn't explicitly wish not to | than having some strange use flags that don't mean what they're named | like. That's like saying "well we should just link against whatever's available, it's far more intuitive than letting the user decide". -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
Ciaran McCreesh wrote: You can do it through bashrc. But then, if this is about working around Portage's annoying lack of sane cross compile handling, why not put a little effort into fixing it properly rather than a lot of effort into making the tree more complicated? Err, I think you're mixing up different things. How should portage be able to do sane cross compiling if you control the instruction sets through use flags which are blocked in profiles the build system is using? In fact, moving away from use flags over to the real(TM) solution is a step towards fixing the issue. Also, it doesn't make the tree more complicated. It is far more intuitive that supported instruction sets are used if the user doesn't explicitly wish not to than having some strange use flags that don't mean what they're named like. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 6 Jul 2006 13:49:39 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Thu, 6 Jul 2006 14:29:39 +0200 "Diego 'Flameeyes' Pettenò" > <[EMAIL PROTECTED]> wrote: > | On Thursday 06 July 2006 14:19, Ciaran McCreesh wrote: > | > Sounds rather flaky and unreliable... > | Sounds rather vague and without arguments. > > Well, you're assuming that a) everyone's using a C compiler, > b) that gcc has the slightest clue what it's doing, We're mostly talking about specially-written assembler code, not stuff like vectorisation or the intrinsics (which very few packages use, if any). > c) that the user has no > problem using nasty hacks to regain control, Control is easy. Specify the relevant -march in CFLAGS. > d) that this information is only needed at compile time, Where a package does run-time detection, there's no need for any conditional compilation as they build for everything anyway, so such packages wouldn't use mmx/sse/sse2 etc USE flags anyway. > e) that various gcc internal definitions won't change... Unlikely for these macros, as that would break a lot of existing code regardless what we do. > You're adding a lot of complexity, and > thus room for very weird breakages, to something that doesn't need it. I'd argue the current approach is the more complex approach, involving the user having to discover the relationship between their processor (which they've already set via -march in CFLAGS) and the various bits that their processor has. There are relatively few packages affected (<1%), so I think it's worth a try. In the end it may be that a few packages need to deal with stuff manually like with the current USE flags, but they'd be local USE flags at that point. -- Kevin F. Quinn signature.asc Description: PGP signature
[gentoo-dev] Re: autotools - 'make' infinite loop
Finally, this was caused by a missing one-liner Makefile.am, it was already fixed upstream but didn't make it into the tarball. Thanks anyway for the suggestions. Marcus, -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 06 Jul 2006 16:03:47 +0200 Simon Stelling <[EMAIL PROTECTED]> wrote: | Ciaran McCreesh wrote: | > Well, you're assuming that a) everyone's using a C compiler, b) that | > gcc has the slightest clue what it's doing, c) that the user has no | > problem using nasty hacks to regain control, d) that this | > information is only needed at compile time, e) that various gcc | > internal definitions won't change... You're adding a lot of | > complexity, and thus room for very weird breakages, to something | > that doesn't need it. | | as for... | | b) You kind of have to assume that when running a system that was | compiled from ground up with gcc Not really true. GCC can be quite happily wrong about what your CPU could support, so long as it's not told to use it. This happens with VIS, for example. | c) This is not about "regaining" control. Currently, users who want | to cross-compile are screwed and need nasty use.mask-hacks to not end | up with broken binaries. The inability to provide per-package CFLAGS | is a missing feature in portage, it's got nothing to do with this | issue. You can do it through bashrc. But then, if this is about working around Portage's annoying lack of sane cross compile handling, why not put a little effort into fixing it properly rather than a lot of effort into making the tree more complicated? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
