Xref: utzoo comp.sys.att:8303 unix-pc.general:4374 misc.wanted:7303 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!shadooby!sharkey!itivax!wotan!scs From: scs@wotan (Steve Simmons) Newsgroups: comp.sys.att,unix-pc.general,misc.wanted Subject: Re: 3B1/7300 Development set wanted Keywords: 3B1, 7300, UNIX-PC, Development set Message-ID: <4671@itivax.iti.org> Date: 19 Dec 89 16:44:53 GMT References: <4309@rtech.rtech.com> <399@quad.uucp> <10129@zodiac.ADS.COM> <401@quad.uucp> Sender: news@itivax.iti.org Distribution: usa Lines: 100 XFoo: bar Status: OR dts@quad.uucp (David T. Sandberg) writes: >In article <10129@zodiac.ADS.COM> neville@hebron.ADS.COM (Neville Newman) writes: >:In article <399@quad.uucp> dts@quad.uucp (David T. Sandberg) writes: >:Now i get to ask - why? Wouldn't it be better in the long run to >:get of couple of compiler writers to modify gas (GNU Assembler) >:and family to generate/understand Unix-PC object files? >Well, I can't speak for anyone else, but I avoid all GNU software on >principle - I don't agree with Stallman's ideas. Besides, there's a >lot more to the development set than just a compiler and assembler. Speaking as one who seriously looked at doing the above: There are a number of utilities from the FSF binary utilities that would need to be ported: gas (assembler) and ld (the linker) are absolutely required. In addition strip, nm, and size would be nice (and are trivial). The primary problem is the symbol table (a.k.a. 'stab') format. FSF binutils are (were? I haven't looked recently) firmly based on UC Berkeley format symbol tables. AT&T uses the Common Object File Format (COFF). Since /lib/libc.a and its friends are all firmly COFF files, there are two choices: Modify gas to output COFF format, modify ld to read/output COFF format, modify strip/nm/size to use COFF format. A lot of work. Or... Use a FSF utility called 'robotussin' (coff medicine) to translate the COFF format lib.a files into BSD stab files. Change all your lib.a files, then happily run with FSF binutils. At first the latter sounds very attractive. Be warned, tho, there is a price: you lose the shared libraries. Since this results in radically larger object files and executables, you pay a severe penalty on small memory/small disk machines (like, for example, the Unix PC). There might be a third solution: follow the first route, but hack FSF ld to understand and link 3b1 shared libraries. But to do that you need the development set, and if you have the development set you don't need to do it -- so nobody's done it. Yet. From scs Tue Dec 19 11:34:59 1989 From: scs Newsgroups: comp.sys.att,unix-pc.general,misc.wanted Subject: Re: 3B1/7300 Development set wanted Keywords: 3B1, 7300, UNIX-PC, Development set Distribution: usa References: <4309@rtech.rtech.com> <399@quad.uucp> <10129@zodiac.ADS.COM> <401@quad.uucp> Status: OR dts@quad.uucp (David T. Sandberg) writes: >In article <10129@zodiac.ADS.COM> neville@hebron.ADS.COM (Neville Newman) writes: >:In article <399@quad.uucp> dts@quad.uucp (David T. Sandberg) writes: >:Now i get to ask - why? Wouldn't it be better in the long run to >:get of couple of compiler writers to modify gas (GNU Assembler) >:and family to generate/understand Unix-PC object files? >Well, I can't speak for anyone else, but I avoid all GNU software on >principle - I don't agree with Stallman's ideas. Besides, there's a >lot more to the development set than just a compiler and assembler. Speaking as one who seriously looked at doing the above: There are a number of utilities from the FSF binary utilities that would need to be ported: gas (assembler) and ld (the linker) are absolutely required. In addition strip, nm, and size would be nice (and are trivial). The primary problem is the symbol table (a.k.a. 'stab') format. FSF binutils are (were? I haven't looked recently) firmly based on UC Berkeley format symbol tables. AT&T uses the Common Object File Format (COFF). Since /lib/libc.a and its friends are all firmly COFF files, there are two choices: Modify gas to output COFF format, modify ld to read/output COFF format, modify strip/nm/size to use COFF format. A lot of work. Or... Use a FSF utility called 'robotussin' (coff medicine) to translate the COFF format lib.a files into BSD stab files. Change all your lib.a files, then happily run with FSF binutils. At first the latter sounds very attractive. Be warned, tho, there is a price: you lose the shared libraries. Since this results in radically larger object files and executables, you pay a severe penalty on small memory/small disk machines (like, for example, the Unix PC). There might be a third solution: follow the first route, but hack FSF ld to understand and link 3b1 shared libraries. But to do that you need the development set, and if you have the development set you don't need to do it -- so nobody's done it. Yet. -- Steve Simmons Just another midwestern boy scs@vax3.iti.org -- or -- ...!sharkey!itivax!scs "Think of c++ as an object-oriented assembler..."