Re: Proposed obsoletions
Nathanael == Nathanael Nerode [EMAIL PROTECTED] writes: Nathanael Paul Koning wrote: Nathanael == Nathanael Nerode [EMAIL PROTECTED] writes: Nathanael * pdp11-*-* (generic only) Useless generic. I believe this one generates DEC (as opposed to BSD) calling conventions, so I'd rather keep it around. It also generates .s files that can (modulo a few bugfixes I need to get in) be assembled by gas. Nathanael Hmm, OK. Could it be given a slightly more descriptive Nathanael name, perhaps? Sure, I'll add that to my list. paul
Re: Proposed obsoletions
Paul Koning wrote: Nathanael == Nathanael Nerode [EMAIL PROTECTED] writes: Nathanael * pdp11-*-* (generic only) Useless generic. I believe this one generates DEC (as opposed to BSD) calling conventions, so I'd rather keep it around. It also generates .s files that can (modulo a few bugfixes I need to get in) be assembled by gas. Hmm, OK. Could it be given a slightly more descriptive name, perhaps? paul
Re: Proposed obsoletions
Mark Mitchell wrote: Daniel Jacobowitz wrote: On Sun, Jun 05, 2005 at 12:41:43PM -0400, Nathanael Nerode wrote: * mips-wrs-windiss * powerpc-wrs-windiss I don't think these were supposed to be in the FSF tree at all, were they? This question belongs more in this thread than in the fixproto one so I'll reask it: Why do you think this? I seem to remember asking about this some years ago, and finding out that its existence was not documented anywhere public, which it still isn't. It's also odd that a VxWorks simulation environment is sufficiently different from VxWorks that it needs a different configuration. Putting it more strongly, I think these should stay. OK, I stand corrected. WindISS is a Wind River simulation environment (including C library), and is still available; Wind River ships WindISS with some of its development platforms. OK. :-) Your job to keep it running. Care to list yourself in MAINTAINERS? I know that we've been promising pdated VxWorks configurations for a long time, and it's reasonable to wonder if we're serious. But, we are; we've been pushing out the VxWorks 6.x binutils bits actively of late, and as soon as those are in, we'll do GCC. We want the binutils bits to go in first, so that we can test the GCC bits with the actual FSF binutils bits. Our current internal versions are based on GCC 3.3.2 and we have some ugly binutils hacks that are being cleaned up as we push out to the FSF.
Re: Proposed obsoletions
Jan-Benedict Glaw wrote: On Sun, 2005-06-05 12:41:43 -0400, Nathanael Nerode [EMAIL PROTECTED] wrote: * vax-*-bsd* * vax-*-sysv* If anyone is still using these, GCC probably doesn't run already. I certainly haven't seen any test results. Correct me if I'm wrong! And after some staring, I think these are bad models for new ports. vax-*-sysv* is probably dead. NetBSD using a.out most probably, too. Actually, that's BSD 4.3/4.4 there. (vax-*-bsd*) Though, vax-netbsdelf may be fine up. At least, I can get vax-linux (or vax-elf) compiler (only adding some 5 lines for configury) that works and produces a correctly working Linux kernel image (see eg. http://www.pergamentum.com/pipermail/linux-vax/2005-May/02.html). So VAXens shape isn't most probably all that bad right now. Yes, I absolutely think vax-netbsdelf should be kept; we know that it works.
Re: Proposed obsoletions
Nathanael Nerode wrote: I seem to remember asking about this some years ago, and finding out that its existence was not documented anywhere public, which it still isn't. It's also odd that a VxWorks simulation environment is sufficiently different from VxWorks that it needs a different configuration. It's not a VxWorks simulation environment; it's a Wind River simulation environment. It's an instruction set simulator, with some additional capabilities. WindISS is a Wind River simulation environment (including C library), and is still available; Wind River ships WindISS with some of its development platforms. OK. :-) Your job to keep it running. Care to list yourself in MAINTAINERS? I think I personally would be a suboptimal choice, though better than nothing. But, yes, someone or someones at CodeSourcery would definitely be a good choice. Dan Jacobowitz and/or Nathan Sidwell and/or Phil Edwards would be good choices. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Proposed obsoletions
Nathanael == Nathanael Nerode [EMAIL PROTECTED] writes: Nathanael * pdp11-*-* (generic only) Useless generic. I believe this one generates DEC (as opposed to BSD) calling conventions, so I'd rather keep it around. It also generates .s files that can (modulo a few bugfixes I need to get in) be assembled by gas. paul
Re: Proposed obsoletions
On Sun, 2005-06-05 12:41:43 -0400, Nathanael Nerode [EMAIL PROTECTED] wrote: * vax-*-bsd* * vax-*-sysv* If anyone is still using these, GCC probably doesn't run already. I certainly haven't seen any test results. Correct me if I'm wrong! And after some staring, I think these are bad models for new ports. vax-*-sysv* is probably dead. NetBSD using a.out most probably, too. Though, vax-netbsdelf may be fine up. At least, I can get vax-linux (or vax-elf) compiler (only adding some 5 lines for configury) that works and produces a correctly working Linux kernel image (see eg. http://www.pergamentum.com/pipermail/linux-vax/2005-May/02.html). So VAXens shape isn't most probably all that bad right now. If you like, I'd submit the configury patch (by Kenn Humborg; copyright assignment should be in place right now) and at least submit a gcc test result for a i686-linux hosted vax-linux cross compiler. (But this doesn't look all that good because we haven't yet integrated userland support into gcc-HEAD nor an emulator to run tests on.) But after all, work is done on the VAX target (and two patches in my queue) in gcc as well as in binutils and there had been recent check-ins in both of these. As a side note: the uClibc folks do have a number of patches allowing gcc to configure against *-uclibc. How is the acceptance of these patches? MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O fuer einen Freien Staat voll Freier Brger | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: Proposed obsoletions
On Sun, Jun 05, 2005 at 12:41:43PM -0400, Nathanael Nerode wrote: * mips-wrs-windiss * powerpc-wrs-windiss I don't think these were supposed to be in the FSF tree at all, were they? This question belongs more in this thread than in the fixproto one so I'll reask it: Why do you think this? -- Daniel Jacobowitz CodeSourcery, LLC
Re: Proposed obsoletions
Daniel Jacobowitz wrote: On Sun, Jun 05, 2005 at 12:41:43PM -0400, Nathanael Nerode wrote: * mips-wrs-windiss * powerpc-wrs-windiss I don't think these were supposed to be in the FSF tree at all, were they? This question belongs more in this thread than in the fixproto one so I'll reask it: Why do you think this? Putting it more strongly, I think these should stay. WindISS is a Wind River simulation environment (including C library), and is still available; Wind River ships WindISS with some of its development platforms. I know that we've been promising pdated VxWorks configurations for a long time, and it's reasonable to wonder if we're serious. But, we are; we've been pushing out the VxWorks 6.x binutils bits actively of late, and as soon as those are in, we'll do GCC. We want the binutils bits to go in first, so that we can test the GCC bits with the actual FSF binutils bits. Our current internal versions are based on GCC 3.3.2 and we have some ugly binutils hacks that are being cleaned up as we push out to the FSF. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
