wsinpdb@lso.win.tue.nl (Paul de Bra) (07/04/90)
In article <551@csource.oz.au> david@csource.oz.au (david nugent) writes: >Has anyone managed to get GNU's assembler running under Interactive >386/ix yet? I got it to compile with few problems, but now I'm faced >with what appears to be an 'incompatible' a.out format that it seems >to be producing. The object files it produces are rejected by the >linker. Yep, you need to use the GNU loader, and all other binutils, as the object format is indeed different. (you need a different ar, nm, strip,...) There also is a util to convert the normal libraries to GNU format, so as to be able to link gcc-gas generated code with standard libs. Going with gas is a serious commitment. But it can become necessary when you start hitting bugs or limitations in the AT&T assembler or linker (as you do with g++) Paul. (debra@research.att.com)
david@csource.oz.au (david nugent) (07/04/90)
Has anyone managed to get GNU's assembler running under Interactive
386/ix yet? I got it to compile with few problems, but now I'm faced
with what appears to be an 'incompatible' a.out format that it seems
to be producing. The object files it produces are rejected by the
linker.
This is probably one of those projects for a 'rainy day', but I don't
enjoy re-inventing the wheel much. :-) So if anyone does have it
running, I'd really like to know about it - especially if diffs are
available, or at least a description of what I should do.
Does anyone know which 386 Unix was used for the port? MicroPort or
AT&T?
Thanks,
david
--
_______________________________________________________________________________
Unique Computing Pty Ltd Melbourne Australia - Communications Specialists
david@csource.oz.au 3:632/348@fidonet 28:4100/1@signet pinard@IRO.UMontreal.CA (Francois Pinard) (07/05/90)
In article <551@csource.oz.au> david@csource.oz.au (david nugent) writes:
Has anyone managed to get GNU's assembler running under Interactive
386/ix yet?
As you probably know already, this assembler is producing BSD
compatible output, which is not the COFF format in use with System V
systems. You should install GNU binutils too, among which there is a
`ld' replacement, and convert your libraries. You probably also want
the GNU C compiler and would appreciate to have the GNU debugger
(GDB). You loose shared libraries (I do not have the feeling of
loosing very much). You gain a nice set of development tools, and you
modestly participate in spreading the Free Software spirit around.
I know this sounds like a lot of work to install; in any case, it was
not trivial for me. However, I did it and now, I would not go back.
I'm quite glad to use all the GNU tools: all the sources are provided
and there is a tremendous support from the community, at least if I
compare with the supplier (ISC)'s support.
--
Franc,ois Pinard ``Vivement GNU!'' pinard@iro.umontreal.ca
(514) 588-4656 cp 886 L'Epiphanie (Qc) J0K 1J0 ...!uunet!iros1!pinarddavid@csource.oz.au (david nugent) (07/05/90)
In comp.unix.i386 you write: >>Has anyone managed to get GNU's assembler running under Interactive >>386/ix yet? I got it to compile with few problems, but now I'm faced >>with what appears to be an 'incompatible' a.out format that it seems >>to be producing. The object files it produces are rejected by the >>linker. >Yep, you need to use the GNU loader, and all other binutils, as the >object format is indeed different. (you need a different ar, nm, strip,...) >There also is a util to convert the normal libraries to GNU format, >so as to be able to link gcc-gas generated code with standard libs. Ahh, thanks! I'm only just starting out on the (apparently long) road to getting most of the gnu stuff going here. Fortunately, I have most of it, but hadn't got anywhere near binutils yet. :-) This is excellent news; I had almost left the project alone for some time because of this stumbling block. gcc works fine (in fact _brilliantly_). >Going with gas is a serious commitment. Good. I'm prepared for it. I have to port a complete C library, and I needed a tool that I can take to as many other machines without having to worry too much about the tools themselves. >But it can become necessary when you start hitting bugs or limitations >in the AT&T assembler or linker (as you do with g++) I've already hit 'em. :-( And that's just with gcc - it produces some code occasionally which /bin/as just can't handle. Looking at the .s produced, I can't see why it's complaining at all sometimes. The sources for the Unix lharc, for example - lzhuf.c -> lzhuf.s just won't assemble after being compiled via gcc. BTW, have you come across the problem with passing non-const literal strings to some library functions? Causes "bus error" and memory faults. It seems that literals used as arguments or as initialisers to statically declared pointers are placed in a "read only" segment data area (perhaps this is an ANSI C requirement?). I'm finding I have to change a bunch of code as a result, first copying the literal into a local buffer, then passing the buffer address to the function. To demonstrate, one function which particularly hurts is mktemp(), since it changes it's argument (at least in ISC's library): I have to change: fptr = mktemp ("/tmp/xyzXXXXXX"); to: char localbuf[PATHLEN]; strcpy (localbuf, "/tmp/xyzXXXXXX"); fptr = mktemp (localbuf); Alternatively; static char localbuf[[PATHLEN] = "/tmp/xyzXXXXXX"; fptr = mktemp (localbuf); I tend to favour the second method, since it reinitialises the variable on each call to the function. Hmm, I just thought of another workaround: replace mktemp() and strdup() the new string (requiring no changed in code). Only problem is that it never gets free()'d which could cause unnecessary memory fragmentation. Thanks again for the help, david -- _______________________________________________________________________________ Unique Computing Pty Ltd Melbourne Australia - Communications Specialists david@csource.oz.au 3:632/348@fidonet 28:4100/1@signet