Re: gcc3.x issues
* Joe Kelsey [EMAIL PROTECTED] [020207 09:36] wrote: David O'Brien writes: On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. David's comments are unhelpful and terse. Quite a difference in attitude. And you wonder why it is so hard to get new volunteers. We have plenty of volunteers willing to point out problems, what would be even more helpful is people _submitting the fixes_ to these problems. Not like problem reporting isn't important, but you can't fault David not being willing to take the time to implement a feature he doesn't find all that important. In fact you should be happy that he'd be willing to review and commit code when it does appear. David has made it quite clear to me in the past that he is absolutely not interested in anyone else ever touching the gcc port in the base system. I have no desire to do anything when faced with such an attitude. Actually David routinely requests assistance and would like to offload some if not all of the gcc maintainance, the problem he's having is finding people capable and willing to do the work rather than people that just want to draft emails complaining about his current work. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Personally I don't have time to engage in a debate, and I doubt that David does either. By stating that he would consider patches he's already given you the go-ahead to do the work, if it's up to par with the project's guidlines there should be minimal fuss with integration. Thanks for your helpful and pleasant comments David. Yeah, whatever, don't we all feel better now? :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Thu, Feb 07, 2002 at 01:30:22PM -0500, Nat Lanza wrote: Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. Yes there is. Earlier on in the thread I would have used your language. But at this point we are deep in a thread in which I've explained the issues and many people don't seem to be listening. Thus you get the language showing my frustration. Sorry I'm only human. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Thu, Feb 07, 2002 at 09:40:31AM -0800, Joe Kelsey wrote: David O'Brien writes: On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. No it is not. If you were a committer you would get the same answer from me. You are expecting me (or someone else) to go to a lot of trouble to do something. Yet it seems you have not investigated how much work it would take. So this is the typical: I don't see the need for this and do not want to do the work needed to do this. However, you are free to do the desired work yourself and also show everyone else it can be done (and maybe easily done). It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. I have given answers in other emails. Now it is your turn. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. Helpful? I do not think so -- because doing that is VERY MUCH NOT SUPPORTED, nor something we really want people doing because many of know all the pairals(sp?) that will come of it. This is not only a FreeBSD-thing. Linux systems do not support you taking any random C compiler (or even GCC) and compiling a working Linux kernel with it. If you have a need for a compiler different than the one bundled with your Linux distribution, you are expected to install it in /usr/local (or your favorite non-/usr/bin place). David has made it quite clear to me in the past that he is absolutely not interested in anyone else ever touching the gcc port in the base system. I have no desire to do anything when faced with such an attitude. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Thanks for your helpful and pleasant comments David. And people wonder why I hate maintaining FreeBSD's GCC and have dropped maintenance of it. (and why many committers are feeling very burnt out by users right now) My current GCC 3.1 work is purely because it is needed for work I am interested in doing -- porting to sparc64, StrongARM, and AMD x86-64. After I am done with the GCC 3.1 work I am doing, you are more than welcomed to become a committer and maintain GCC for us all. Or you can pay me a reasonable salary and then I'll do your every GCC wish. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Alfred Perlstein wrote: Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. A lot of us are punch-drunk with the upcoming BSDCon next week, too. The flipness of the comments aside (don't hold people's personalities against them, Joe), doing a patch would be a way to handle this. I offered to help with the structural stuff, but not write the patch itself, since I'm not really a great follower of -current, and patches not against current are frequently ignored by committers because they don't represent the latest, greatest thing. I still haven't figured out how to hande the dichotomy of most volunteer work occurring in -current, while most commercial work on FreeBSD occurs in the last RELEASE, or, to a lesser extent, -stable. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. David's comments are unhelpful and terse. Quite a difference in attitude. And you wonder why it is so hard to get new volunteers. We have plenty of volunteers willing to point out problems, what would be even more helpful is people _submitting the fixes_ to these problems. Not like problem reporting isn't important, but you can't fault David not being willing to take the time to implement a feature he doesn't find all that important. In fact you should be happy that he'd be willing to review and commit code when it does appear. It's not a trivial problem to fix, either. It's tangled up in the make release process, which is two measures of intent down the road from the question that Joe asked. I volunteered structural help (which would probably be mostly just explaqining the status quo, so that anyone writing the code could avoid breakage), and David volunteered to do reviews of the resulting patches, which is tantamount to volunteering to commit them, so long as they aren't incredibly offensive. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Personally I don't have time to engage in a debate, and I doubt that David does either. I don't think Joe is debating; I think he wants to have a meta-discussion about what the problem space looks like, before submitting patches that light up his little corner, and dark up everything else. Every time these tools issues come up, it really boils down to the GNU build process sucking pretty hard, not being very seperable, and, in general, expecting to be installed in isolation as an add on, rather than as an integral part of a larger whole. You really can't hold David responsible for that, it's a vendor problem that doesn't look to be solved any time soon. USL is the same way: they have some incredibly smart stuff, but interacting with them is like sharing a prison cell with a 500 pound man named Bubba, even if you are their employee. Maybe especially if you are their employee... guards have to see Bubba every day of their career, while short timers have the promise that their Bubba days will soon be over. 8-). It's also not obvious that the DESTDIR phenomenon exists with compilers from ports, until you get going and it bites you on the arse. David is the compiler maintainer, so it's second nature to him to turn around and smack problems as they are preparing to bite. 8-). The rest of us end up with rather more tender backsides... 8-) 8-). I don't think that this is going to be resolved right before BSDCon, when everyone is feeling incredible time pressure, and those who aren't are having the stress rubbed off onto them by the others. I also don't think that this is a shallow problem that's subject to easy dismissal. But if it's a choice between have some, everything works, and have all, some works, the everything works wins hands down. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Thu, 2002-02-07 at 12:59, Alfred Perlstein wrote: These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. One provides an opportunity for users to contribute, and the other is a snarling, rude dismissal that really doesn't do very much to encourage people to stick around and help out. --nat To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: So what? When I install gcc on a non-native platform (such as HP-UX or Solaris), Again, WHAT IS THE PROBLEM you are trying to solve? Just laziness of not being willing to type ``pkg_add -r gcc30'' or ``pkg_add -r gcc31''? Because it installs in non-default places. It creates duplicates of gcc, all libraries and is a potential source of error and confusion over what is the *real* supported compiler. Uh, sorry, pkg_add -r gcc30 will install the software in _exactaly_ the same place as you would get GCC on one of your non-native platforms. You will also get a duplicate C compiler (besides acc [HPUX], or cc [Solaris]). So why does all this bother you on FreeBSD and not those platforms? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Joe Kelsey wrote: David O'Brien writes: 3. Are you going to maintain them? If we did do this work and allowed people to optinally install gjc and Ada, I bet only 5% would do so (other than the initial turning it on just to see what the compilers looked like). What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. 1: Are you going to provide the Makefile glue to do this? If not, then shut the hell up. 2: We need to get a *basic* compiler up and running first. Give David a break, ok? There are far bigger problems to deal with first before futzing around on obscure languages that we have no critical need for in the base system. We ***NEED*** the ability to compile basic C code for the sparc64, ia64 and x86-64 platforms. Until that is dealt with, the rest is a luxury. 3: Once we have the basics running, *then* maybe we can talk about compile knobs. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
hi, there! On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: So what? Just because it wasn't part of 4.2 BSD, does that mean that we should never support it? 2. What is so hard with installing the port. No one has answered *THAT* question yet. Ports are installed in /usr/local. gcc is installed in /usr. Either provide a way to install *all* of gcc as part of the system, or provide a *suppported* way to *replace* it with a port. I do not want to have two versions of gcc fighting for disk space and confusing users over PATH issues. please calm down. seems that you have never installed gcc from ports. gcc 2.95 from ports is installed as gcc295/g++295 and correctly gets its bits from /usr/local/lib/gcc-lib/xxx, gcc 3.0x from ports is named gcc30/g++30 and so on. There is no PATH issue. Switching between compilers is as easy as setting correct CC/CXX environment/Makefile variables. argument about disk space sounds a bit funny these days. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
David O'Brien writes: On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. David's comments are unhelpful and terse. Quite a difference in attitude. And you wonder why it is so hard to get new volunteers. David has made it quite clear to me in the past that he is absolutely not interested in anyone else ever touching the gcc port in the base system. I have no desire to do anything when faced with such an attitude. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Thanks for your helpful and pleasant comments David. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
* Nat Lanza [EMAIL PROTECTED] [020207 10:30] wrote: On Thu, 2002-02-07 at 12:59, Alfred Perlstein wrote: These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. One provides an opportunity for users to contribute, and the other is a snarling, rude dismissal that really doesn't do very much to encourage people to stick around and help out. No, they both offer users a chance to conribute, however the second let's the person know that they are bordering on annoying the person and should take some time to work on the actual implementation. Would you rather have someone's irritation or just be killfiled? Some people need to buck up and grow a thicker skin. Neither I nor David are in anyway compensated directly through our involvement in the FreeBSD project to pull punches nor coddle people that should know better. Moving forward, let's postpone taking this conversation any further until the time that the work requested does become available. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Terry Lambert writes: I don't think Joe is debating; I think he wants to have a meta-discussion about what the problem space looks like, before submitting patches that light up his little corner, and dark up everything else. Thank you, Terry. Maybe I need to bring up the issue on -arch? Where is it possible to have design discussions without getting slapped down with the submit a patch or shut up attitude? I personally work by doing design first, or at least getting to the point where I understand the problem before tackling it in an incremental design/build cycle. Maybe someone can point out the design documentation for the whole complex mk hierarchy and/or for the design behind the importation of gcc and other GNU stuff into the source tree. Or maybe the design is the code... I appreciate your offer of assistance, Terry. I will take your last pointer into the make files and see what I can deduce on my own. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Max Khon wrote:
please calm down. seems that you have never installed gcc from ports.
gcc 2.95 from ports is installed as gcc295/g++295
and correctly gets its bits from /usr/local/lib/gcc-lib/xxx,
gcc 3.0x from ports is named gcc30/g++30 and so on.
There is no PATH issue. Switching between compilers is as easy as
setting correct CC/CXX environment/Makefile variables.
And hacking the Makefile a lot to specify command line
arguments in the compiler program definition itself, so
that the /usr/include/g++ files that came with the old
compiler are not used for make release and other types
of make targets where DESTDIR is fairly mandatory.
See /usr/src/share/mk/bsd.prog.mk, ~line 14:
.if defined(DESTDIR) !defined(BOOTSTRAPPING)
CFLAGS+= -I${DESTDIR}/usr/include
CXXINCLUDES+= -I${DESTDIR}/usr/include/g++
.endif
See also /usr/src/share/mk/bsd.lib.mk, ~line 40.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
David O'Brien writes: On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. David's comments are unhelpful and terse. Quite a difference in attitude. And you wonder why it is so hard to get new volunteers. David has made it quite clear to me in the past that he is absolutely not interested in anyone else ever touching the gcc port in the base system. I have no desire to do anything when faced with such an attitude. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Thanks for your helpful and pleasant comments David. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
* Joe Kelsey [EMAIL PROTECTED] [020207 09:36] wrote: David O'Brien writes: On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. David's comments are unhelpful and terse. Quite a difference in attitude. And you wonder why it is so hard to get new volunteers. We have plenty of volunteers willing to point out problems, what would be even more helpful is people _submitting the fixes_ to these problems. Not like problem reporting isn't important, but you can't fault David not being willing to take the time to implement a feature he doesn't find all that important. In fact you should be happy that he'd be willing to review and commit code when it does appear. David has made it quite clear to me in the past that he is absolutely not interested in anyone else ever touching the gcc port in the base system. I have no desire to do anything when faced with such an attitude. Actually David routinely requests assistance and would like to offload some if not all of the gcc maintainance, the problem he's having is finding people capable and willing to do the work rather than people that just want to draft emails complaining about his current work. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Personally I don't have time to engage in a debate, and I doubt that David does either. By stating that he would consider patches he's already given you the go-ahead to do the work, if it's up to par with the project's guidlines there should be minimal fuss with integration. Thanks for your helpful and pleasant comments David. Yeah, whatever, don't we all feel better now? :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Thu, Feb 07, 2002 at 01:00:19AM -0800, Terry Lambert wrote: Max Khon wrote: please calm down. seems that you have never installed gcc from ports. gcc 2.95 from ports is installed as gcc295/g++295 and correctly gets its bits from /usr/local/lib/gcc-lib/xxx, gcc 3.0x from ports is named gcc30/g++30 and so on. There is no PATH issue. Switching between compilers is as easy as setting correct CC/CXX environment/Makefile variables. And hacking the Makefile a lot to specify command line arguments in the compiler program definition itself, so that the /usr/include/g++ files that came with the old compiler are not used for make release and other types of make targets where DESTDIR is fairly mandatory. Terry, we only support building the world (ie, anything in /usr/src) with the *SYSTEM* compiler. If you are wanting to do: cd /usr/src make CC=FOOcc CXX=FOO++ buildworld Then you are going off into the not-supported woods and you should expect to have to do some hacking. If you are wanting to use /usr/share/mk for your own projects, then that is also a debatable issue. Some claim /usr/share/mk is only for use of /usr/src; others feel it should be generic and truely usable for other code. If you have some well tested patches to fix the assumptions in /usr/share/mk, we might can change things. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Thu, 2002-02-07 at 12:59, Alfred Perlstein wrote: These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. One provides an opportunity for users to contribute, and the other is a snarling, rude dismissal that really doesn't do very much to encourage people to stick around and help out. --nat To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Thu, Feb 07, 2002 at 01:30:22PM -0500, Nat Lanza wrote: Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. Yes there is. Earlier on in the thread I would have used your language. But at this point we are deep in a thread in which I've explained the issues and many people don't seem to be listening. Thus you get the language showing my frustration. Sorry I'm only human. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
* Nat Lanza [EMAIL PROTECTED] [020207 10:30] wrote: On Thu, 2002-02-07 at 12:59, Alfred Perlstein wrote: These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. One provides an opportunity for users to contribute, and the other is a snarling, rude dismissal that really doesn't do very much to encourage people to stick around and help out. No, they both offer users a chance to conribute, however the second let's the person know that they are bordering on annoying the person and should take some time to work on the actual implementation. Would you rather have someone's irritation or just be killfiled? Some people need to buck up and grow a thicker skin. Neither I nor David are in anyway compensated directly through our involvement in the FreeBSD project to pull punches nor coddle people that should know better. Moving forward, let's postpone taking this conversation any further until the time that the work requested does become available. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Alfred Perlstein wrote: Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. This is the atypical, smug, I'm a committer and your're not attitude that permeates so much of the upper echelons of the FreeBSD team. It really makes me sick that people seem to prefer to throw out useless comments like this instead of giving actual answers to valide questions. These comments are not useless, most committers have day jobs that unfortunetly preclude them from having time to work on every little feature request. Furthermore asking for patches is the exact opposite of being smug at least in the way of flaunting one's commit priveledges, it's providing the user an opportunity to present work for inclusion into the project. A lot of us are punch-drunk with the upcoming BSDCon next week, too. The flipness of the comments aside (don't hold people's personalities against them, Joe), doing a patch would be a way to handle this. I offered to help with the structural stuff, but not write the patch itself, since I'm not really a great follower of -current, and patches not against current are frequently ignored by committers because they don't represent the latest, greatest thing. I still haven't figured out how to hande the dichotomy of most volunteer work occurring in -current, while most commercial work on FreeBSD occurs in the last RELEASE, or, to a lesser extent, -stable. I believe that Terry has already pointed out several of the places in the Makefile system that prevent anyone from reinstalling gcc over the top of the standard one. His comments were helpful and succinct. David's comments are unhelpful and terse. Quite a difference in attitude. And you wonder why it is so hard to get new volunteers. We have plenty of volunteers willing to point out problems, what would be even more helpful is people _submitting the fixes_ to these problems. Not like problem reporting isn't important, but you can't fault David not being willing to take the time to implement a feature he doesn't find all that important. In fact you should be happy that he'd be willing to review and commit code when it does appear. It's not a trivial problem to fix, either. It's tangled up in the make release process, which is two measures of intent down the road from the question that Joe asked. I volunteered structural help (which would probably be mostly just explaqining the status quo, so that anyone writing the code could avoid breakage), and David volunteered to do reviews of the resulting patches, which is tantamount to volunteering to commit them, so long as they aren't incredibly offensive. This is a discussion of general principles. After settling the debate, *then* it is appropriate to ask if anyone would like to work on the issues. Then, I may or may not try to generate patches. Personally I don't have time to engage in a debate, and I doubt that David does either. I don't think Joe is debating; I think he wants to have a meta-discussion about what the problem space looks like, before submitting patches that light up his little corner, and dark up everything else. Every time these tools issues come up, it really boils down to the GNU build process sucking pretty hard, not being very seperable, and, in general, expecting to be installed in isolation as an add on, rather than as an integral part of a larger whole. You really can't hold David responsible for that, it's a vendor problem that doesn't look to be solved any time soon. USL is the same way: they have some incredibly smart stuff, but interacting with them is like sharing a prison cell with a 500 pound man named Bubba, even if you are their employee. Maybe especially if you are their employee... guards have to see Bubba every day of their career, while short timers have the promise that their Bubba days will soon be over. 8-). It's also not obvious that the DESTDIR phenomenon exists with compilers from ports, until you get going and it bites you on the arse. David is the compiler maintainer, so it's second nature to him to turn around and smack problems as they are preparing to bite. 8-). The rest of us end up with rather more tender backsides... 8-) 8-). I don't think that this is going to be resolved right before BSDCon, when everyone is feeling incredible time pressure, and those who aren't are having the stress rubbed off onto them by the others. I also don't think that this is a shallow problem that's subject to easy dismissal. But if it's a choice between have some, everything works, and have all, some works, the everything works wins hands down. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Terry Lambert writes: I don't think Joe is debating; I think he wants to have a meta-discussion about what the problem space looks like, before submitting patches that light up his little corner, and dark up everything else. Thank you, Terry. Maybe I need to bring up the issue on -arch? Where is it possible to have design discussions without getting slapped down with the submit a patch or shut up attitude? I personally work by doing design first, or at least getting to the point where I understand the problem before tackling it in an incremental design/build cycle. Maybe someone can point out the design documentation for the whole complex mk hierarchy and/or for the design behind the importation of gcc and other GNU stuff into the source tree. Or maybe the design is the code... I appreciate your offer of assistance, Terry. I will take your last pointer into the make files and see what I can deduce on my own. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
David O'Brien wrote: And hacking the Makefile a lot to specify command line arguments in the compiler program definition itself, so that the /usr/include/g++ files that came with the old compiler are not used for make release and other types of make targets where DESTDIR is fairly mandatory. Terry, we only support building the world (ie, anything in /usr/src) with the *SYSTEM* compiler. If you are wanting to do: cd /usr/src make CC=FOOcc CXX=FOO++ buildworld Then you are going off into the not-supported woods and you should expect to have to do some hacking. The problem I noted is C++ only. I'm sure that there are other cases where it's not, but they're really fuzzy, since I don't have a comprehensive tool chain listing that can get me an explosion if anything from the default chain gets used accidently. Wasn't Eric Melville going to fix this by turning the normal system components into packages? 8-) 8-). For the buildworld case, and the release case, the problem is incredibly deeper than just replacing the day to day use tools, since if you build the compiler as part of the build, you're screwed already. You can make an argument for the release case using a different set of tools, since it can install patches and packages prior to the build process, but the compiler you end up with will be the release compiler, not the package compiler, even though pretty much everything will have been compiled with the package compiler (or cross builds would not work at all). Even so, the interaction is ugly. I think Joe's main problem is that it's not documented, except in the heads of the people who've tried it, or the people who maintain it. Yeah, that's a problem, but the only thing we can really do about it is offer to answer questions, or tell them (or imply with a where's the patches? response) that they are on their own. Documentation won't magically appear (e.g.: where's the patches? 8-)). If you are wanting to use /usr/share/mk for your own projects, then that is also a debatable issue. Some claim /usr/share/mk is only for use of /usr/src; others feel it should be generic and truely usable for other code. If you have some well tested patches to fix the assumptions in /usr/share/mk, we might can change things. Seperate problem. Though if it *were* generic... we might see the BSD make being more widely adopted. I think this is one of the tenets of the Open Ports project, FWIW. If nothing else, FreeBSD ought to be pulling back in their tools changes that they've found to be necessary, so long as they don't hurt too much (a little pain is good for you, according to the penguins...). Personally, if my projects are limited to FreeBSD, I use the .mk system, and if they aren't, then I avoid it like the plague. Building a project based partly on Open Source is really an art, more than it is an easy thing to do, though it's often worth the pain to get the benefits (per my Daemon News article -- shameless plug). I think the biggest barrier these days is that there is so much that is assumed to be part of the base system that is not really generic UNIX, and avoiding contamination from use of, for example, the FreeBSD version of OpenSSL, rather than the version in your source tree, requires that the engineer doing the work cross their T's and dot their I's correctly, or they will find that their code works on their developement machine, but not their target machine. Fixing *that* problem is a lot more than just waving your hands: it requires duct tape and prayers, since you will find yourself fixing the software packages you depend upon, too (this is the major drawback of autconf/automake: unlike imake and xmkmf, they really aren't portability tools, and can't make a program run on a new target through a correct description of the target, like imake can -- e.g. MySQL now runs on AIX again because I hit my head on it, and there are 5 or 6 other Open Source projects that got patches out of my last round of head hitting). In any case, it's often hard to discuss Hoover Dam when you are running low on fingers plugging holes in the local levy; know that your work on the levy *is* appreciated, since we would all be under water otherwise. I'll look at what it will take to fix the DESTDIR stuff without breaking things. That's a far cry from what Joe wanted, but it's a step in that direction, anyway. It's going to boil down to tracking down everywhere it's used in the source tree as is, particularly with regards to the make release case, where the headers have to come in from the target environment, but also in ports. 8-(. Fortunately, there is not a lot of C++ code in the release stuff; the ports stuff will be more problematic, of course, but much of that is already broken, in that the system compiler is passed, but the g++ compiler is searched out and preferred (!@#!$!@ autoconf/automake). ...Uh, don't let me looking at this stop anyone else from looking at it
Re: gcc3.x issues
On Thu, Feb 07, 2002 at 02:55:26PM -0800, Terry Lambert wrote: stuff; the ports stuff will be more problematic, of course, but much of that is already broken, in that the system compiler is passed, but the g++ compiler is searched out and preferred (!@#!$!@ autoconf/automake). env CXX=foo++ ./configure To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On 7 Feb 2002, Nat Lanza wrote: Surely you see the difference between That's an interesting idea; can you generate some patches so we can take a look and see how it works out? and WhereTF is your patch to do this?. One provides an opportunity for users to contribute, and the other is a snarling, rude dismissal that really doesn't do very much to encourage people to stick around and help out. I humbly have to agree that was the way it sounded to me. Im hoping that it was not meant that way, but that was howe it sounded. /Johan --nat To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
David O'Brien wrote: stuff; the ports stuff will be more problematic, of course, but much of that is already broken, in that the system compiler is passed, but the g++ compiler is searched out and preferred (!@#!$!@ autoconf/automake). env CXX=foo++ ./configure I had to be a bit more agressive with the packages I was fighting. I can look up which ones they were, if you want. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Wasn't Eric Melville going to fix this by turning the normal system components into packages? 8-) 8-). Yeah, I'm just rather busy between work and school these days. I'm giving a little presentation on this at BSDCon, hopefully I can rope some more folks in to the project. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
It is plain that many people will want to be able to install a version of gcc that is officially supported and that also includes *all* of the standard platforms that come as part of the gcc release. What is so wrong with being able to specify a compilation flag that says install all of the extra bits that come with gcc. This could be off by default, but be settable on a site-by-site basis for those who feel that installing gcc et al. just once is plenty instead of having to track god knows how many different ports supporting wildly varying versions of gcc. I agree that installing the entire gcc chain is overkill for many small sites, but if you have the horsepower, you can choose appropriate points in the release cycle where you want to install the entire compiler suite (say right after a major release) and set the appropriate flag *at that time* to get the bits you want. Or, it could be a predefined package available for installation that puts all of the compilers in the same place as the standard gcc/g++, i.e., /usr instead of /usr/local. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Wed, Feb 06, 2002 at 05:23:32PM -0800, Joe Kelsey wrote: It is plain that many people will want to be able to install a version of gcc that is officially supported and that also includes *all* of the standard platforms that come as part of the gcc release. You do realize that means Ada for 3.1 don't you? Pascal in the the works. Also that means bringing in Chill also for 2.95 and later. What is so wrong with being able to specify a compilation flag that says install all of the extra bits that come with gcc. 1. They are not needed by the base system, nor are the part of a traditional BSD system. 2. What is so hard with installing the port. No one has answered *THAT* question yet. 3. Are you going to maintain them? If we did do this work and allowed people to optinally install gjc and Ada, I bet only 5% would do so (other than the initial turning it on just to see what the compilers looked like). I agree that installing the entire gcc chain is overkill for many small sites, but if you have the horsepower, you can choose appropriate points in the release cycle where you want to install the entire compiler suite (say right after a major release) and set the appropriate flag *at that time* to get the bits you want. Or, it could be a predefined package available for installation that puts all of the compilers in the same place as the standard gcc/g++, i.e., /usr instead of /usr/local. Again, WHAT IS THE PROBLEM you are trying to solve? Just laziness of not being willing to type ``pkg_add -r gcc30'' or ``pkg_add -r gcc31''? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
David O'Brien writes: On Wed, Feb 06, 2002 at 05:23:32PM -0800, Joe Kelsey wrote: It is plain that many people will want to be able to install a version of gcc that is officially supported and that also includes *all* of the standard platforms that come as part of the gcc release. You do realize that means Ada for 3.1 don't you? Pascal in the the works. Also that means bringing in Chill also for 2.95 and later. So what? When I install gcc on a non-native platform (such as HP-UX or Solaris), I install the whole thing regardless of whether or not I personally will use all of the bits right away. What is so wrong with being able to specify a compilation flag that says install all of the extra bits that come with gcc. 1. They are not needed by the base system, nor are the part of a traditional BSD system. So what? Just because it wasn't part of 4.2 BSD, does that mean that we should never support it? 2. What is so hard with installing the port. No one has answered *THAT* question yet. Ports are installed in /usr/local. gcc is installed in /usr. Either provide a way to install *all* of gcc as part of the system, or provide a *suppported* way to *replace* it with a port. I do not want to have two versions of gcc fighting for disk space and confusing users over PATH issues. 3. Are you going to maintain them? If we did do this work and allowed people to optinally install gjc and Ada, I bet only 5% would do so (other than the initial turning it on just to see what the compilers looked like). What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. I agree that installing the entire gcc chain is overkill for many small sites, but if you have the horsepower, you can choose appropriate points in the release cycle where you want to install the entire compiler suite (say right after a major release) and set the appropriate flag *at that time* to get the bits you want. Or, it could be a predefined package available for installation that puts all of the compilers in the same place as the standard gcc/g++, i.e., /usr instead of /usr/local. Again, WHAT IS THE PROBLEM you are trying to solve? Just laziness of not being willing to type ``pkg_add -r gcc30'' or ``pkg_add -r gcc31''? Because it installs in non-default places. It creates duplicates of gcc, all libraries and is a potential source of error and confusion over what is the *real* supported compiler. What is so wrong with allowing someone to choose at system build time what parts of gcc to build into the base system. I already agreed with you that the default should be just gcc and g++. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Joe Kelsey wrote: David O'Brien writes: On Wed, Feb 06, 2002 at 05:23:32PM -0800, Joe Kelsey wrote: It is plain that many people will want to be able to install a version of gcc that is officially supported and that also includes *all* of the standard platforms that come as part of the gcc release. You do realize that means Ada for 3.1 don't you? Pascal in the the works. Also that means bringing in Chill also for 2.95 and later. So what? When I install gcc on a non-native platform (such as HP-UX or Solaris), I install the whole thing regardless of whether or not I personally will use all of the bits right away. How many MB does your flash card where you're installing FreeBSD have on it? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: So what? When I install gcc on a non-native platform (such as HP-UX or Solaris), Again, WHAT IS THE PROBLEM you are trying to solve? Just laziness of not being willing to type ``pkg_add -r gcc30'' or ``pkg_add -r gcc31''? Because it installs in non-default places. It creates duplicates of gcc, all libraries and is a potential source of error and confusion over what is the *real* supported compiler. Uh, sorry, pkg_add -r gcc30 will install the software in _exactaly_ the same place as you would get GCC on one of your non-native platforms. You will also get a duplicate C compiler (besides acc [HPUX], or cc [Solaris]). So why does all this bother you on FreeBSD and not those platforms? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
David O'Brien wrote: On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: What is so hard about allowing someone to specify the list of frontends to provide at system build time? I thought that gcc was supposed to be a modular compiler system, You thought wrong. 8-). and that all we are asking for is the ability to add to the default front ends, along with the default support libraries, in the default places. Uh Joe... WhereTF is your patch to do this? My or your MTA seems to have deleted it. 8-) 8-) 8-). Actually, you could do the Makefile hacks pretty easily, if there were an unconfig'ed full source code in the tree to work from... not that I'm volunteering... if Joe wants help doing that, I can help him out on structure. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
In message: [EMAIL PROTECTED] Terry Lambert [EMAIL PROTECTED] writes: : How many MB does your flash card where you're installing : FreeBSD have on it? I've installed a subsetted FreeBSD onto a 8MB CF card. For normal FreeBSD (as oppsoed to pico), the smallest amount of space you need is about 6.9M, and that can be stripped down to about 5M with compression and custom rc files with network stuff. However, to do a standard install, the minimal installation takes about a 128M 196M part (but I haven't tried it lately). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Peter Wemm [EMAIL PROTECTED] writes: 2: We need to get a *basic* compiler up and running first. Give David a break, ok? There are far bigger problems to deal with first before futzing around on obscure languages that we have no critical need for in the base system. We ***NEED*** the ability to compile basic C code for the sparc64, ia64 and x86-64 platforms. Until that is dealt with, the rest is a luxury. Yes, absolutely. Every minute David spends replying to these idiotic suggestions wastes valuable project time. How many FreeBSD users need to compile Java to machine code? 2, 3, 4 people? How hard is it to use `pkg_add -r' and rearrange your PATH to make a stock GCC work? Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
At 5:23 PM -0800 2/6/02, Joe Kelsey wrote: It is plain that many people will want to be able to install a version of gcc that is officially supported and that also includes *all* of the standard platforms that come as part of the gcc release. This line of reasoning does not scale up well. It is plain that people will want to install 'ruby', because ruby is necessary for the VERY USEFUL port known as 'portupgrade'. People will also want to install autoconf and automake. I have about seventy ports installed, all of which I think are very useful and very nice to have. Most of them are ports that many other people will also want to install. All of them are ports I would use more often than gjc, and I am someone who *likes* working with computer languages. However, many people wanting a particular port does not justify moving it into the base system. You talk as if the ports collection is only for things that nobody wants. This is an odd view of ports. You talk as if ports are not officially supported. It is true that some of them are orphans, but other ports are supported just as well and just as fervently as anything in the base system. I think David is 100% right in his position. That position is that unless there is some major reason that gjc *must* be in the base system, then it can survive quite well as a port. I have read through your messages, and I have seen no convincing reason why gjc *must* be in the base system. Personally, I see no reason at all. This is not meant as an insult against gjc. It's simply a matter of what does and does not belong in the base system. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
: How many MB does your flash card where you're installing : FreeBSD have on it? I've installed a subsetted FreeBSD onto a 8MB CF card. For normal FreeBSD (as oppsoed to pico), the smallest amount of space you need is about 6.9M, and that can be stripped down to about 5M with compression and custom rc files with network stuff. However, to do a standard install, the minimal installation takes about a 128M 196M part (but I haven't tried it lately). I've got 4.5-PRE pico on a floppy that boots on a 486/66, but it's *really* tight (10k available). If I login to the box remotely and try to run anything, it kills the login process so it's pretty useless. With another 4-8MB of memory, the box would actually work pretty well as a dedicated wireless firewall/router/snooper. For now, it works pretty good as a wireless router/simple packet filter. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
On Wed, 2002-02-06 at 23:46, Mike Barcroft wrote: Yes, absolutely. Every minute David spends replying to these idiotic suggestions wastes valuable project time. How many FreeBSD users need to compile Java to machine code? 2, 3, 4 people? How hard is it to use `pkg_add -r' and rearrange your PATH to make a stock GCC work? You know, people might be less persistent about these idiotic suggestions if they got treated with some civility and respect. It's a lot more meaningful and useful to receive an explanation, even a brief one, about why your suggestion isn't good than it is to receive personal abuse. If you simply abuse someone, they're just going to think you're a jerk, not that their ideas are bad. More flies with honey, and all that. I've noticed a lot of nastiness in this thread, and it's really pretty disappointing. Yes, you're all busy people. Yes, this is a volunteer project. Yes, people are never satisfied with what others do for them for free. That sucks, sure. But it doesn't make it okay to treat people like crap for daring to disagree with you. --nat To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
hi, there! On Wed, Feb 06, 2002 at 05:47:07PM -0800, Joe Kelsey wrote: So what? Just because it wasn't part of 4.2 BSD, does that mean that we should never support it? 2. What is so hard with installing the port. No one has answered *THAT* question yet. Ports are installed in /usr/local. gcc is installed in /usr. Either provide a way to install *all* of gcc as part of the system, or provide a *suppported* way to *replace* it with a port. I do not want to have two versions of gcc fighting for disk space and confusing users over PATH issues. please calm down. seems that you have never installed gcc from ports. gcc 2.95 from ports is installed as gcc295/g++295 and correctly gets its bits from /usr/local/lib/gcc-lib/xxx, gcc 3.0x from ports is named gcc30/g++30 and so on. There is no PATH issue. Switching between compilers is as easy as setting correct CC/CXX environment/Makefile variables. argument about disk space sounds a bit funny these days. /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.x issues
Nat Lanza [EMAIL PROTECTED] writes: You know, people might be less persistent about these idiotic suggestions if they got treated with some civility and respect. From what I read, the participants in this thread were very civil and respectful. I don't think the original poster had given his suggestion much thought before bringing it up though. :( It's a lot more meaningful and useful to receive an explanation, even a brief one, about why your suggestion isn't good than it is to receive personal abuse. If you simply abuse someone, they're just going to think you're a jerk, not that their ideas are bad. I completely agree. I found David's explanations quite helpful in determining the legitimacy of the original suggestion. More flies with honey, and all that. I've noticed a lot of nastiness in this thread, and it's really pretty disappointing. Yes, you're all busy people. Yes, this is a volunteer project. Yes, people are never satisfied with what others do for them for free. That sucks, sure. But it doesn't make it okay to treat people like crap for daring to disagree with you. I didn't notice much nastiness, but I guess I wasn't really looking for it. I did notice that some people were wasting a developer's time when the project as a whole needs it much more. I'm talking, ofcourse, about the imminent GCC upgrade that David is working on. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
