web browsers (was: Re: aout support broken in gcc3)
Thus spake Terry Lambert [EMAIL PROTECTED]: Mozilla, Galeon, and other browsers claim to be better, but often fail to provide features that have been in Netscape for forever. You mean features like being stable, at least sometimes? Efficiency? IMO, Mozilla has features up the kazoo, but the developers seem unwilling to pursue unfashionable goals such as making a browser that just works. And in terms of security, a buggy browser worries me a lot more than Linux emulation. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: web browsers (was: Re: aout support broken in gcc3)
Mozilla, Galeon, and other browsers claim to be better, but often fail to provide features that have been in Netscape for forever. You mean features like being stable, at least sometimes? Efficiency? IMO, Mozilla has features up the kazoo, but the developers seem unwilling to pursue unfashionable goals such as making a browser that just works. And in terms of security, a buggy browser worries me a lot more than Linux emulation. The Gecko engine developed by the Mozilla Project, however seems to be very good. I find Galeon quite nice, as it uses Mozilla's quite capable HTML rendering engine, has its own well designed GTK-based GUI, and has little of Mozilla's bloat. Netscape Navigator = 4.? has quite bad HTML rendering, and is disliked greatly by most web developers I know (not to condone it, but it's little wonder that many web sites are now designed for Internet Explorer). I would suggest to anybody still using Netscape 4 on a Unix platform that they try a replacement browser, whether that be Mozilla, Galeon, or something else (perhaps Opera or Konqueror). If you're looking for a replacement Internet mail client, you might like to try Mutt, Balsa, Sylpheed, or Evolution. -- MICHAEL WARDLE SGI Desktop and Sysadmin Software Adacel Technologies Limited To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: web browsers (was: Re: aout support broken in gcc3)
Thus spake Michael WARDLE [EMAIL PROTECTED]: The Gecko engine developed by the Mozilla Project, however seems to be very good. I find Galeon quite nice, as it uses Mozilla's quite capable HTML rendering engine, has its own well designed GTK-based GUI, and has little of Mozilla's bloat. Netscape Navigator = 4.? has quite bad HTML rendering, and is disliked greatly by most web developers I know (not to condone it, but it's little wonder that many web sites are now designed for Internet Explorer). I would suggest to anybody still using Netscape 4 on a Unix platform that they try a replacement browser, whether that be Mozilla, Galeon, or something else (perhaps Opera or Konqueror). I quite agree that everything fell apart with the 4.x browser wars. The standards-compliance aspect is improving, but at the rate browsers seem to be going, I'm going to need another processor just to surf the web pretty soon. I've tried Mozilla, Opera, and Skipstone and found intolerable shortcomings and annoyances in each. I'm reluctant to try Galeon because I don't have the bloat that is Gnome anymore, and if I reinstalled it all for the sake of a web browser, I would also seriously need a bigger hard drive. I may go back to Skipstone. It's minimalistic enough that if it's been under active development since I last used it, it's probably pretty stable. If you're looking for a replacement Internet mail client, you might like to try Mutt, Balsa, Sylpheed, or Evolution. I already use mutt; I don't like clicky interfaces. I wish there were a web browser that worked as well as mutt, and I think it's too bad that lynx is inadequate for rendering complicated web pages these days. Followups, if any, to -chat, where the subscribers are used to this topic coming up all the time... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
You are blowing this out of proportion and not actually reading what people are proposing. So far, the comments are about removing a.out support from the base compiler and offering a.out binutils and gcc _as ports_. That would be sufficient for my needs (a matching gdb would be useful too, I'm not sure if that is part of binutils). But I don't think my concern was misplaced: having gone back through the thread for the past couple of weeks, there were certainly phrases like drop all traces of a.out support if you need to generate new ones (?) unpack a 2.2.6 system with the ports solution mentioned only if we really have to have a.out. -- Richard (running Franz Lisp since 1983) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
Terry Lambert [EMAIL PROTECTED] wrote: Bruce Evans wrote: Isn't this too old and security-holed to use? It stopped being packaged a few releases ago. 4.5R has mainly: /usr/local/lib/netscape-linux/communicator-linux-4.79.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped and mozilla. I personally use the FreeBSD native Netscape. I'd like to as well - but I found that with version 4.5 and later (the move to XFree86 4.x) that the FreeBSD Netscape refused to run. There is a rather long discussion of what I found in the -stable archives I believe... - Dave R. - -- [EMAIL PROTECTED]Work: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: web browsers (was: Re: aout support broken in gcc3)
Michael WARDLE wrote: The Gecko engine developed by the Mozilla Project, however seems to be very good. I find Galeon quite nice, as it uses Mozilla's quite capable HTML rendering engine, has its own well designed GTK-based GUI, and has little of Mozilla's bloat. If it isn't broken, don't fix it. If you're looking for a replacement Internet mail client, you might like to try Mutt, Balsa, Sylpheed, or Evolution. I like my applications to have the same look-and-feel. I like them to use the same shortcut keys for the same functions, etc.. Unfortunately, kmail and konquerer just aren't there yet, and even though GTK has a style guide, no one is very religious about following it. Reminds me a lot of a UI person I used to know who prototyped all her UI stuff in Visual BASIC, and then expected us to be able to implement things like modal dialogues in HTML, so that browser-based access to the device resembled a Windows application. She totally refused to be constrained by HTML during the design process, even though that was what we had to deploy on. Made it a real pain in the ass: everyone who has to deal with UI code was effectively painting pixels with an 8 foot paint brush. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On 04-Sep-2002 Richard Tobin wrote: You are blowing this out of proportion and not actually reading what people are proposing. So far, the comments are about removing a.out support from the base compiler and offering a.out binutils and gcc _as ports_. That would be sufficient for my needs (a matching gdb would be useful too, I'm not sure if that is part of binutils). But I don't think my concern was misplaced: having gone back through the thread for the past couple of weeks, there were certainly phrases like drop all traces of a.out support if you need to generate new ones (?) unpack a 2.2.6 system with the ports solution mentioned only if we really have to have a.out. Well, I think what happened is that people wanted to know if others still needed a.out and thus if ports should be created. I guess some people have been saying some more drastic things then that and it is hard to know who to listen to. :-/ It is a good thing to point out user's needs but accusing developers of never taking the long-term view (which you did not do, I know) is not a good way to win others over to one's argument. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: web browsers (was: Re: aout support broken in gcc3)
On Wed, 4 Sep 2002 16:54:02 +1000, Michael WARDLE [EMAIL PROTECTED] said: for Internet Explorer). I would suggest to anybody still using Netscape 4 on a Unix platform that they try a replacement browser, whether that be Mozilla, Galeon, or something else (perhaps Opera or Konqueror). Mozilla has an intolerable (read: Windows) user interface. Konqueror is a dog (at least on my machine), even though you can reprogram the user interface somewhat, and its SSL/TLS support is barely functional. Neither program works properly with my bank's online banking service. I'll stick with something that works, and works fast. I'm well aware of the security issues, and have determined the risk to be insignificant for the way I use a Web browser. (And frankly, I don't much care what lusing Web-design weenies think about it.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002 23:32:22 +0100 (BST), Richard Tobin [EMAIL PROTECTED] said: So they need a C compiler that can generate a.out format .o files, and a linker that can link a.out format .o files against an a.out format executable. Not necessarily. There is always `objcopy', at least for static executables. The version we ship doesn't support any flavor of a.out, but that wouldn't be too difficult to fix if it solved this particular problem. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
* De: Garrett Wollman [EMAIL PROTECTED] [ Data: 2002-09-04 ] [ Subjecte: Re: aout support broken in gcc3 ] On Tue, 3 Sep 2002 23:32:22 +0100 (BST), Richard Tobin [EMAIL PROTECTED] said: So they need a C compiler that can generate a.out format .o files, and a linker that can link a.out format .o files against an a.out format executable. Not necessarily. There is always `objcopy', at least for static executables. The version we ship doesn't support any flavor of a.out, but that wouldn't be too difficult to fix if it solved this particular problem. Or elf2aout could be used? -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
You are blowing this out of proportion and not actually reading what people are proposing. So far, the comments are about removing a.out support from the base compiler and offering a.out binutils and gcc _as ports_. A port is fine -- but this was proposed much later in the thread. Unfortunately there is no such direct back-pressure in the open source community and developers usually don't have a long term view. Thank you for insulting our intelligence. Sorry you see it that way -- I certainly didn't mean to insult anyone's intelligence. It is just the way I see it -- programmers want to program neat new things (or clean up code or make thinge more elegant, faster, more modular, more generic and so on) and users just want to continue using what they are comfortable with -- even when they want to play with new and shiny things. I believe both groups should participate in deciding the direction FreeBSD takes. That is what will bring out the best without breaking old things. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Mon, Sep 02, 2002 at 12:42:47PM -0700, Julian Elischer wrote: On Mon, Sep 02, 2002 at 01:24:19PM -0400, Matthew Emmerton wrote: I thought it was part of the plan to drop all traces of a.out support in 5.x. Am I wrong? We should be *very* careful to accurately describe what is being suggested. I believe it is that 5.x a.out binaries not be supported. However, 2.x a.out binaries will be supported. This is different thatn drop all traces of a.out support. yes binary support will remain.. if you need to generate new ones (?) unpack a 2.2.6 system into a chroot tree (jail?) and make it there :-) *sigh* This *still* isn't clear what is being suggested. (also seen in other emails in this thread, just picked this one to repond to) This is what BDE said: Actually, I agree. Not having a clean break in FreeBSD-3 was very expensive. Support for running aout binaries and compatibility cruft to support old binaries should have been dropped too. This is NOT a toolchain issue he is talking about, but a kernel one. Please forget all about the toolchain issue. It is a non-issue. I and kan are the only ones that it has inconvinced. Everyone else has been able to totally ignore it. I'll probably do something about it next week. _The_ issue is to understand exactly what is being discussed about compatibility cruft to support old binaries should have been dropped tooQ. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, David O'Brien wrote: This is NOT a toolchain issue he is talking about, but a kernel one. Please forget all about the toolchain issue. It is a non-issue. I and kan are the only ones that it has inconvinced. Everyone else has been able to totally ignore it. I'll probably do something about it next week. I think that the ability to run 2.2.6 binaries should remain. the ability to generate them or even debug them can be almost completely removed.. there are always other ways to do that (e.g. boot 2.2.6 in a vmware machine or run them in a chroot) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
GCC being able to produce a.out format binaries has nothing to do with the ability of a Lisp or Prolog to compile to object files, Correct. and read such, whether said object files be a.out or ELF or COFF or PECOFF or Mach-O or ... False. As I said, I have systems that read a.out format object files and they would need to be ported to read ELF object files instead. Furthermore, they write themselves out (after loading object files) in a.out format, and would need to be ported to write themselves out in ELF format. -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, David O'Brien wrote: On Mon, Sep 02, 2002 at 12:42:47PM -0700, Julian Elischer wrote: yes binary support will remain.. if you need to generate new ones (?) unpack a 2.2.6 system into a chroot tree (jail?) and make it there :-) *sigh* This *still* isn't clear what is being suggested. (also seen in other emails in this thread, just picked this one to repond to) This is what BDE said: Actually, I agree. Not having a clean break in FreeBSD-3 was very expensive. Support for running aout binaries and compatibility cruft to support old binaries should have been dropped too. This is NOT a toolchain issue he is talking about, but a kernel one. Please forget all about the toolchain issue. It is a non-issue. I and kan are the only ones that it has inconvinced. Everyone else has been able to totally ignore it. I'll probably do something about it next week. _The_ issue is to understand exactly what is being discussed about compatibility cruft to support old binaries should have been dropped tooQ. Well, I meant everything (large parts of COMPAT_43, and kernel support for aout...). I was half joking about the kernel support. It would have been very painful to drop it in 3.0R. Now it seems to be too late to even think about dropping it for 5.0R. However, we should start deprecating it more, and I think some of the COMPAT_43 stuff is a better/ easier place to start than kern/imgact_aout.c. Most of it is probably only used by old aout binaries. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
Julian Elischer wrote: On Tue, 3 Sep 2002, David O'Brien wrote: This is NOT a toolchain issue he is talking about, but a kernel one. Please forget all about the toolchain issue. It is a non-issue. I and kan are the only ones that it has inconvinced. Everyone else has been able to totally ignore it. I'll probably do something about it next week. I think that the ability to run 2.2.6 binaries should remain. So, you could live with 'options COMPAT_AOUT' or 'kldload i386_aout' or something like that? the ability to generate them or even debug them can be almost completely removed.. there are always other ways to do that (e.g. boot 2.2.6 in a vmware machine or run them in a chroot) 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
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, Peter Wemm wrote: Julian Elischer wrote: On Tue, 3 Sep 2002, David O'Brien wrote: This is NOT a toolchain issue he is talking about, but a kernel one. Please forget all about the toolchain issue. It is a non-issue. I and kan are the only ones that it has inconvinced. Everyone else has been able to totally ignore it. I'll probably do something about it next week. I think that the ability to run 2.2.6 binaries should remain. So, you could live with 'options COMPAT_AOUT' or 'kldload i386_aout' or something like that? for me that would be enough. Can't speak for others though.. as on -hackers or somewhere.. maybe even on -announce Announce: Planned removal of default support for a.out and see if anyone screams :-) the ability to generate them or even debug them can be almost completely removed.. there are always other ways to do that (e.g. boot 2.2.6 in a vmware machine or run them in a chroot) 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
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, Peter Wemm wrote: Julian Elischer wrote: On Tue, 3 Sep 2002, David O'Brien wrote: This is NOT a toolchain issue he is talking about, but a kernel one. Please forget all about the toolchain issue. It is a non-issue. I and kan are the only ones that it has inconvinced. Everyone else has been able to totally ignore it. I'll probably do something about it next week. I think that the ability to run 2.2.6 binaries should remain. So, you could live with 'options COMPAT_AOUT' or 'kldload i386_aout' or something like that? As long as I can set things up so that a chroot to an environment full of 2.2.6 binaries will still work, then I can still support sites with embedded 2.2.6 based things.. Others may find this a requirement too. the ability to generate them or even debug them can be almost completely removed.. there are always other ways to do that (e.g. boot 2.2.6 in a vmware machine or run them in a chroot) 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: aout support broken in gcc3
On Tue, 3 Sep 2002 09:31:52 -0700 (PDT), Julian Elischer [EMAIL PROTECTED] said: As long as I can set things up so that a chroot to an environment full of 2.2.6 binaries will still work, then I can still support sites with embedded 2.2.6 based things.. Others may find this a requirement too. I think more people probably care about this: /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact demand paged dynamically linked executable -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
* De: Richard Tobin [EMAIL PROTECTED] [ Data: 2002-09-03 ] [ Subjecte: Re: aout support broken in gcc3 ] GCC being able to produce a.out format binaries has nothing to do with the ability of a Lisp or Prolog to compile to object files, Correct. and read such, whether said object files be a.out or ELF or COFF or PECOFF or Mach-O or ... False. As I said, I have systems that read a.out format object files and they would need to be ported to read ELF object files instead. Furthermore, they write themselves out (after loading object files) in a.out format, and would need to be ported to write themselves out in ELF format. Where exactly does GCC fit into the mix, making this impossible? -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
False. As I said, I have systems that read a.out format object files and they would need to be ported to read ELF object files instead. Furthermore, they write themselves out (after loading object files) in a.out format, and would need to be ported to write themselves out in ELF format. Where exactly does GCC fit into the mix, making this impossible? They compile Lisp (etc) to a C file, which they compile (with gcc) to a .o file, then link against the running image (with /usr/libexec/aout/ld -A) to produce a relocated .o file, then read it in and look at its symbol table to find the entry points. So they need a C compiler that can generate a.out format .o files, and a linker that can link a.out format .o files against an a.out format executable. I'm quite expecting the answer yes, we've considered this and decided that the overhead of supporting it is to much, but I want to make sure that you realise that there are programs that will break. Long-time BSD users will not be surprised to know that Franz Lisp (the original BSD Franz Lisp, not the commercial Franz Inc product) is one of them. Incidentally, I know that the modern alternative to reading in .o files is to use shared libraries instead, but as far as I know there isn't any support for writing out an executable that has shared libraries mapped in (so that they don't have to be loaded, or even exist, when the program is started again). -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, Sep 03, 2002 at 11:32:22PM +0100, Richard Tobin wrote: False. As I said, I have systems that read a.out format object files and they would need to be ported to read ELF object files instead. Furthermore, they write themselves out (after loading object files) in a.out format, and would need to be ported to write themselves out in ELF format. Where exactly does GCC fit into the mix, making this impossible? They compile Lisp (etc) to a C file, which they compile (with gcc) to ^^^ actually with as(1), because gcc is only generates assembler file, which is then translated into the object file by assembler (as). Assembler by itself is part of binutils, not a compiler suite. -Maxim a .o file, then link against the running image (with /usr/libexec/aout/ld -A) to produce a relocated .o file, then read it in and look at its symbol table to find the entry points. So they need a C compiler that can generate a.out format .o files, and a linker that can link a.out format .o files against an a.out format executable. I'm quite expecting the answer yes, we've considered this and decided that the overhead of supporting it is to much, but I want to make sure that you realise that there are programs that will break. Long-time BSD users will not be surprised to know that Franz Lisp (the original BSD Franz Lisp, not the commercial Franz Inc product) is one of them. Incidentally, I know that the modern alternative to reading in .o files is to use shared libraries instead, but as far as I know there isn't any support for writing out an executable that has shared libraries mapped in (so that they don't have to be loaded, or even exist, when the program is started again). -- Richard 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: aout support broken in gcc3
Where exactly does GCC fit into the mix, making this impossible? They compile Lisp (etc) to a C file, which they compile (with gcc) to ^^^ actually with as(1), because gcc is only generates assembler file, which is then translated into the object file by assembler (as). Assembler by itself is part of binutils, not a compiler suite. I suspect Richard Tobin was using the generally accepted meaning for a compiler as one that translates a source program into object code (machine language). In any case, it is cc1 that generates an assembly file. gcc is just a driver program that calls various subprograms. Richard's main point with which I totally agree is that please do not take away the ability to generate and grok a.out files *if at all possible*. A number of Lisp systems as well as Scheme one use ld -A friends to do what he described. In general, please do not break backward compatibility. meta-discussion Seems to me that most of the FreeBSD developers are not heavy 3rd part software users. Consequently they (the developers) do not realize that even when sources are available it is not always easy to update them to support changes that break old code -- due to lack of time or money or inability or inexperience to change the 3rd party software or whatever. When sources are not available, you are up the proverbial creek. You may say just continue running old freeBSD kernels but the constant stream of security fixes makes hard to justify doing that. IMHO what is needed is a strong voice for the *users* (along with hackers/developers) in influencing the direction FreeBSD takes -- right now if you don't hack FreeBSD code, you don't get listened to very much. This is like letting a builder build a house, or worse, letting an architect design a house without input from the people who are going to live in it [trust me, you want a 4000 sq ft house on your 4500 sq ft lot, with humongous walkin closets, tiny bedrooms, a big master bathroom with large french windows in the shower (so what if it is facing your neighbor's living room windows only 10 ft away)]. In a commercial setting it is the user who ultimately pays the development costs so they do get listened to (or the company dies). As an example, on a modern SGI machine you can still run 20 year old binaries -- providing such compatibility is a pain and not pretty but to long time users' their dusty decks are very valuable. Unfortunately there is no such direct back-pressure in the open source community and developers usually don't have a long term view. /meta-discussion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On 03-Sep-2002 Bakul Shah wrote: Where exactly does GCC fit into the mix, making this impossible? They compile Lisp (etc) to a C file, which they compile (with gcc) to ^^^ actually with as(1), because gcc is only generates assembler file, which is then translated into the object file by assembler (as). Assembler by itself is part of binutils, not a compiler suite. I suspect Richard Tobin was using the generally accepted meaning for a compiler as one that translates a source program into object code (machine language). In any case, it is cc1 that generates an assembly file. gcc is just a driver program that calls various subprograms. Richard's main point with which I totally agree is that please do not take away the ability to generate and grok a.out files *if at all possible*. A number of Lisp systems as well as Scheme one use ld -A friends to do what he described. In general, please do not break backward compatibility. meta-discussion Seems to me that most of the FreeBSD developers are not heavy 3rd part software users. Consequently they (the developers) do not realize that even when sources are available it is not always easy to update them to support changes that break old code -- due to lack of time or money or inability or inexperience to change the 3rd party software or whatever. When sources are not available, you are up the proverbial creek. You may say just continue running old freeBSD kernels but the constant stream of security fixes makes hard to justify doing that. You are blowing this out of proportion and not actually reading what people are proposing. So far, the comments are about removing a.out support from the base compiler and offering a.out binutils and gcc _as ports_. Thus, people who needed to work with a.out can still install a toolchain to work with, they just wouldn't use the toolchain in the base system. The toolchain in the base system would then be easier to maintain resulting in it being more up-to-date and it would also be a bit faster. Unfortunately there is no such direct back-pressure in the open source community and developers usually don't have a long term view. Thank you for insulting our intelligence. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, Garrett Wollman wrote: On Tue, 3 Sep 2002 09:31:52 -0700 (PDT), Julian Elischer [EMAIL PROTECTED] said: As long as I can set things up so that a chroot to an environment full of 2.2.6 binaries will still work, then I can still support sites with embedded 2.2.6 based things.. Others may find this a requirement too. I think more people probably care about this: /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact demand paged dynamically linked executable Isn't this too old and security-holed to use? It stopped being packaged a few releases ago. 4.5R has mainly: /usr/local/lib/netscape-linux/communicator-linux-4.79.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped and mozilla. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, Bakul Shah wrote:
Where exactly does GCC fit into the mix, making this impossible?
They compile Lisp (etc) to a C file, which they compile (with gcc) to
^^^
actually with as(1), because gcc is only generates assembler file,
which is then translated into the object file by assembler (as).
Assembler by itself is part of binutils, not a compiler suite.
Actually, it is part of old binutils, which is in FreeBSD's src tree but
hasn't been built by default for many years. Therefore it doesn't even
compile (except in my version of course):
%%%
Script started on Wed Sep 4 14:26:54 2002
ttyp0:bde@besplex:/tmp cvs -Q co as
ttyp0:bde@besplex:/tmp cd as
ttyp0:bde@besplex:/tmp/as make
Warning: Object directory not changed from original /tmp/as
updating targ-cpu.h...
updating obj-format.h...
updating host.h...
updating targ-env.h...
cc -O -pipe -DNON_BROKEN_WORDS -DPIC -I/tmp/as -I/tmp/as -I/tmp/as/config -DOLD_GAS
-DSIGTY=void -Derror=as_fatal -DSUB_SEGMENT_ALIGN=4 -DFREEBSD_AOUT-c
/tmp/as/config/tc-i386.c
In file included from /tmp/as/as.h:78,
from /tmp/as/config/tc-i386.c:31:
/usr/include/stdio.h:324: syntax error before '(' token
*** Error code 1
Stop in /tmp/as.
ttyp0:bde@besplex:/tmp/as exit
Script done on Wed Sep 4 14:27:04 2002
%%%
This is because misimplemented compatibility cruft setbuffer() was finally
bitten by reality.
I suspect Richard Tobin was using the generally accepted
meaning for a compiler as one that translates a source
program into object code (machine language). In any case, it
is cc1 that generates an assembly file. gcc is just a driver
program that calls various subprograms.
I suspect that he is also using old binaries for as and ld. It
would be safer to use an old compiler driver with them too.
Richard's main point with which I totally agree is that
please do not take away the ability to generate and grok
a.out files *if at all possible*. A number of Lisp systems
as well as Scheme one use ld -A friends to do what he
described. In general, please do not break backward
compatibility.
But must we support building new versions of the a.out utilities
and keep all the infrastructure (man pages and objformat...) up
to date? We haven't been doing that properly since 3.0R. Some
of te infrastructure is still built by default, but parts must be
built manually (as, ld, gdb ...) or old versions must be copied
from somewhere. gdb is most problematic (if you need it) since
old gdb's don't work out with current kernels. You have to check
out gdb-mumble from FreeBSD-mumble and recompile.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
Bruce Evans wrote: Isn't this too old and security-holed to use? It stopped being packaged a few releases ago. 4.5R has mainly: /usr/local/lib/netscape-linux/communicator-linux-4.79.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped and mozilla. I personally use the FreeBSD native Netscape. I dislike loading the Linux emulator, for security reasons. Mozilla, Galeon, and other browsers claim to be better, but often fail to provide features that have been in Netscape for forever. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
Apparently, On Mon, Sep 02, 2002 at 02:24:08PM +1000,
Bruce Evans said words to the effect of;
aout support is still required for a few things (mainly for compiling
some boot blocks), but is broken in gcc3 for at least compile-time
Which boot blocks?
assignments to long longs and shifts of long longs by a non-constant
amount:
%%%
$ cat z.c
long long x = 0;
int y;
foo()
{
x = x y;
}
$ cc -O -S -aout z.c
$ cat z.s
.file z.c
.globl _x
.data
.p2align 3
.type _x,@object
.size _x,8
_x:
.quad 0
.text
.p2align 2,0x90
.globl _foo
.type _foo,@function
_foo:
pushl %ebp
movl%esp, %ebp
movb_y, %cl
movl_x, %eax
movl_x+4, %edx
shldl %eax, %edx
sall%cl, %eax
testl $32, %ecx
je L2
movl%eax, %edx
movl$0, %eax
L2:
movl%eax, _x
movl%edx, _x+4
leave
ret
Lfe1:
.size _foo,Lfe1-_foo
.comm_y,4
.ident GCC: (GNU) 3.1 [FreeBSD] 20020509 (prerelease)
%%%
The above assembler output has two syntax errors:
- .quad 0. .quad is not supported by the old aout assembler.
- shldl %eax, %edx. The old aout assembler only accepts the correct
syntax of shldl %cl,%eax,%edx. Note that gcc doesn't elide the
similarly implicit %cl register for the sall instruction.
Bruce
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: aout support broken in gcc3
On Mon, 2 Sep 2002, Jake Burkholder wrote:
Apparently, On Mon, Sep 02, 2002 at 02:24:08PM +1000,
Bruce Evans said words to the effect of;
aout support is still required for a few things (mainly for compiling
some boot blocks), but is broken in gcc3 for at least compile-time
Which boot blocks?
Oops, perhaps only mine. (I use my version of biosboot which is like
pc98/boot2 except it supports loading elf kernels and some local things,
and it hasn't been converted to elf at the source level.) When I wrote
the above I thought that several standard boot blocks used OBJFORMAT=-aout.
They actually just have a lot of ${OBJFORMAT} == aout ifdefs and
elf2aout conversions. Most of aout support at the source level seems to
have been broken some time ago by using new gas features in assembler
code.
The above assembler output has two syntax errors:
- .quad 0. .quad is not supported by the old aout assembler.
- shldl %eax, %edx. The old aout assembler only accepts the correct
syntax of shldl %cl,%eax,%edx. Note that gcc doesn't elide the
similarly implicit %cl register for the sall instruction.
Wrong fixes for .quad are easy and are already done for some systems
(e.g., OpenBSD) by #undefing ASM_QUAD.
The following hack seems to fix shld (the breakage seems to be
intentional):
%%%
Index: i386.md
===
RCS file: /home/ncvs/src/contrib/gcc/config/i386/i386.md,v
retrieving revision 1.12
diff -u -2 -r1.12 i386.md
--- i386.md 1 Sep 2002 21:13:32 - 1.12
+++ i386.md 2 Sep 2002 05:51:30 -
@@ -10768,5 +10768,5 @@
@
shld{l}\t{%2, %1, %0|%0, %1, %2}
- shld{l}\t{%s2%1, %0|%0, %1, %2}
+ shld{l}\t{%2, %1, %0|%0, %1, %2}
[(set_attr type ishift)
(set_attr prefix_0f 1)
%%%
I forgot to make the corresponding change for shrd.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
Bruce Evans wrote:
On Mon, 2 Sep 2002, Jake Burkholder wrote:
Apparently, On Mon, Sep 02, 2002 at 02:24:08PM +1000,
Bruce Evans said words to the effect of;
aout support is still required for a few things (mainly for compiling
some boot blocks), but is broken in gcc3 for at least compile-time
Which boot blocks?
Oops, perhaps only mine. (I use my version of biosboot which is like
pc98/boot2 except it supports loading elf kernels and some local things,
and it hasn't been converted to elf at the source level.) When I wrote
the above I thought that several standard boot blocks used OBJFORMAT=-aout.
They actually just have a lot of ${OBJFORMAT} == aout ifdefs and
elf2aout conversions. Most of aout support at the source level seems to
have been broken some time ago by using new gas features in assembler
code.
I've been of the opinion for a while that it is well past time to remove
the hybrid a.out/ELF support in the compiler and stop pretending that we
support a.out. All it does these days is slow down the compiler in the
usual case by pushing what are traditional compile-time decisions to
runtime. As you point out, it hasn't worked for a while.
FreeBSD-3.x was a hybrid a.out/elf system
FreeBSD-4.x had vague a.out support but it was not installed by default. It
may not have been officially deprecated, but was all but.
FreeBSD-5.x should IMHO be a.out free.
We have a couple of things that still use a.out and they are fairly well
encapsulated. btxld can produce a.out formats for the loader etc even when
fed ELF source files. elf2aout is also there for the few cases that it is
needed.
The point of updating the toolchain was so that we could use non-archaic
assembler syntax.
If somebody really wants to build a.out stuff, I would suggest that the
thing to do there is to build a binutils with static a.out support (ie:
have a modern gas) and a gcc configured for a.out. Most of the binutils
bits and bmake glue are around for building an a.out binutils in our tree
(or in the Attic). We can possibly configure two different cc1 etc
backends for a.out and elf if it comes to that.
The only really interesting use for a.out is for interfacing kernels and
boot code with old roms. The current binutils in the tree has sufficient
a.out support for that. It cannot build dynamic binaries or shared libs
though, but that is no big deal.
gcc has grown a native -funderscores option to help with the source
C vs asm symbol compatability problems.
But quite frankly, I'd rather have a binutils-aout and gcc-aout port if we
really have to have a.out support still.
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
Re: aout support broken in gcc3
On Mon, 2 Sep 2002, Peter Wemm wrote: Bruce Evans wrote: On Mon, 2 Sep 2002, Jake Burkholder wrote: Apparently, On Mon, Sep 02, 2002 at 02:24:08PM +1000, Bruce Evans said words to the effect of; aout support is still required for a few things (mainly for compiling some boot blocks), but is broken in gcc3 for at least compile-time Which boot blocks? Oops, perhaps only mine. (I use my version of biosboot which is like pc98/boot2 except it supports loading elf kernels and some local things, and it hasn't been converted to elf at the source level.) When I wrote ... I've been of the opinion for a while that it is well past time to remove the hybrid a.out/ELF support in the compiler and stop pretending that we support a.out. All it does these days is slow down the compiler in the usual case by pushing what are traditional compile-time decisions to runtime. As you point out, it hasn't worked for a while. Except I just used it to compile biosboot :-). (I had more problems with ufs2 changes than with the compiler.) Actually, I agree. Not having a clean break in FreeBSD-3 was very expensive. Support for running aout binaries and compatibility cruft to support old binaries should have been dropped too. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002 01:09:11 +1000 (EST) Bruce Evans [EMAIL PROTECTED] wrote: Except I just used it to compile biosboot :-). (I had more problems with ufs2 changes than with the compiler.) Actually, I agree. Not having a clean break in FreeBSD-3 was very expensive. Support for running aout binaries and compatibility cruft to support old binaries should have been dropped too. Do we have an agreement here? A.OUT support is to be dropped with the next gcc upgrade, when/if it will happen? -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Mon, Sep 02, 2002 at 11:34:48AM -0400, Alexander Kabaev wrote: On Tue, 3 Sep 2002 01:09:11 +1000 (EST) Bruce Evans [EMAIL PROTECTED] wrote: Except I just used it to compile biosboot :-). (I had more problems with ufs2 changes than with the compiler.) Actually, I agree. Not having a clean break in FreeBSD-3 was very expensive. Support for running aout binaries and compatibility cruft to support old binaries should have been dropped too. Do we have an agreement here? A.OUT support is to be dropped with the next gcc upgrade, when/if it will happen? I think it should be turned off now. That will help shake out any issues and people complaining that it is gone. The sooner the better. -gordon msg42464/pgp0.pgp Description: PGP signature
Re: aout support broken in gcc3
On Mon, Sep 02, 2002 at 09:29:05AM -0700, Gordon Tetlow wrote: I think it should be turned off now. That will help shake out any issues and people complaining that it is gone. The sooner the better. It isn't a simple knob to turn it off. It requires several source changes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, Bruce Evans wrote: On Mon, 2 Sep 2002, Peter Wemm wrote: Bruce Evans wrote: On Mon, 2 Sep 2002, Jake Burkholder wrote: Apparently, On Mon, Sep 02, 2002 at 02:24:08PM +1000, Bruce Evans said words to the effect of; aout support is still required for a few things (mainly for compiling some boot blocks), but is broken in gcc3 for at least compile-time Which boot blocks? Oops, perhaps only mine. (I use my version of biosboot which is like pc98/boot2 except it supports loading elf kernels and some local things, and it hasn't been converted to elf at the source level.) When I wrote ... I've been of the opinion for a while that it is well past time to remove the hybrid a.out/ELF support in the compiler and stop pretending that we support a.out. All it does these days is slow down the compiler in the usual case by pushing what are traditional compile-time decisions to runtime. As you point out, it hasn't worked for a while. Except I just used it to compile biosboot :-). (I had more problems with ufs2 changes than with the compiler.) Actually, I agree. Not having a clean break in FreeBSD-3 was very expensive. Support for running aout binaries and compatibility cruft to support old binaries should have been dropped too. I thought it was part of the plan to drop all traces of a.out support in 5.x. Am I wrong? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
David O'Brien wrote: On Mon, Sep 02, 2002 at 09:29:05AM -0700, Gordon Tetlow wrote: I think it should be turned off now. That will help shake out any issues and people complaining that it is gone. The sooner the better. It isn't a simple knob to turn it off. It requires several source changes. Oh indeed, it is far from simple. But as a bonus our compiler configuration for i386 would be a lot closer to what the FSF compiler config looks like. 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
Re: aout support broken in gcc3
On Mon, Sep 02, 2002 at 01:24:19PM -0400, Matthew Emmerton wrote: I thought it was part of the plan to drop all traces of a.out support in 5.x. Am I wrong? We should be *very* careful to accurately describe what is being suggested. I believe it is that 5.x a.out binaries not be supported. However, 2.x a.out binaries will be supported. This is different thatn drop all traces of a.out support. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Mon, 2 Sep 2002, David O'Brien wrote: On Mon, Sep 02, 2002 at 01:24:19PM -0400, Matthew Emmerton wrote: I thought it was part of the plan to drop all traces of a.out support in 5.x. Am I wrong? We should be *very* careful to accurately describe what is being suggested. I believe it is that 5.x a.out binaries not be supported. However, 2.x a.out binaries will be supported. This is different thatn drop all traces of a.out support. yes binary support will remain.. if you need to generate new ones (?) unpack a 2.2.6 system into a chroot tree (jail?) and make it there :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
* De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-09-02 ] [ Subjecte: Re: aout support broken in gcc3 ] On Mon, Sep 02, 2002 at 01:24:19PM -0400, Matthew Emmerton wrote: I thought it was part of the plan to drop all traces of a.out support in 5.x. Am I wrong? We should be *very* careful to accurately describe what is being suggested. I believe it is that 5.x a.out binaries not be supported. However, 2.x a.out binaries will be supported. This is different thatn drop all traces of a.out support. I *hope* nobody is suggesting to rip out the ability to use compat22, let alone the a.out execution facilities in the Kernel. Though maybe making those optional would be good? -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
yes binary support will remain.. if you need to generate new ones (?) You say this as if no-one would want to do it, but I still use programs (lisp and prolog compilers) that need to generate and read in compiled .o files, and undump themselves after reading in such files, and which are never likely to be updated to know about (the much more complicated) elf format. -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
* De: Richard Tobin [EMAIL PROTECTED] [ Data: 2002-09-02 ] [ Subjecte: Re: aout support broken in gcc3 ] yes binary support will remain.. if you need to generate new ones (?) You say this as if no-one would want to do it, but I still use programs (lisp and prolog compilers) that need to generate and read in compiled .o files, and undump themselves after reading in such files, and which are never likely to be updated to know about (the much more complicated) elf format. I think you're extremeley confused. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
I think you're extremeley confused. In what way? Or are you just being rude? -- RIchard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
* De: Richard Tobin [EMAIL PROTECTED] [ Data: 2002-09-02 ] [ Subjecte: Re: aout support broken in gcc3 ] I think you're extremeley confused. In what way? Or are you just being rude? GCC being able to produce a.out format binaries has nothing to do with the ability of a Lisp or Prolog to compile to object files, and read such, whether said object files be a.out or ELF or COFF or PECOFF or Mach-O or ... For example, Mono works with PECOFF32 images, and can read them in and out on Windows, NetBSD, OpenBSD, FreeBSD, Linnex, and probably QNX. And nothing says that '.o' or 'a.out' implies the image is in a.out or ELF or PECOFF or ... format. juli. -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
* De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-09-02 ] [ Subjecte: Re: aout support broken in gcc3 ] On Mon, Sep 02, 2002 at 01:24:19PM -0400, Matthew Emmerton wrote: I thought it was part of the plan to drop all traces of a.out support in 5.x. Am I wrong? We should be *very* careful to accurately describe what is being suggested. I believe it is that 5.x a.out binaries not be supported. However, 2.x a.out binaries will be supported. This is different thatn drop all traces of a.out support. I *hope* nobody is suggesting to rip out the ability to use compat22, let alone the a.out execution facilities in the Kernel. Though maybe making those optional would be good? Sorry, I didn't mean what I said. I meant what Juli suggested (support for compat2x) but removing native 5.x support for a.out, which will help clean up some things in the tools chain. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
