popkin@cs.odu.edu (The Programmer - AI) (12/28/90)
Where can I ftp language compilers and files fro my 386 xenix Please.. email to popkin@xanth.cs.odu.edu Thanks.. Brian
sef@kithrup.COM (Sean Eric Fagan) (12/31/90)
In article <1990Dec27.160543.1943@cs.odu.edu> popkin@cs.odu.edu (The Programmer - AI) writes: >Where can I ftp language compilers and files fro my 386 xenix Please.. If I understand you, that's *theft*. You gots to pay for the development system. If you wait a while, you will probably be able to get gcc and the GNU libc, but they are not both available yet. (And, of course, you'd need an OMF linker, which GNU doesn't support, I believe.) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
ronald@robobar.co.uk (Ronald S H Khoo) (12/31/90)
sef@kithrup.COM (Sean Eric Fagan) writes: > If you wait a while, you will probably be able to get gcc and the > GNU libc, but they are not both available yet. Someone once posted a Xenix system call library, and there's Earl Chew's stdio, and lots of fragments to replace most of the unix libc.a scattered about the net (especially in the BSD directory on uunet :-) I think that's enough to do *lots* of real development with :-) > GNU libc, but they are not both available yet. (And, of course, you'd need > an OMF linker, which GNU doesn't support, I believe.) But he *does* have /bin/ld as part of his LINK KIT in the OS dist, and I don't think there's *anything* SCO can do to stop him using it for purposes other than what it was distributed to him for. /bin/adb is hidden inside one of the OS dist diskettes as well (for patching the kernel with) and GDB has been ported to Xenix. As for ar and ranlib, well, there's /tmp/b1 and /tmp/b2 in various SLS diskettes (like xnx 155b, for example?) but I recommend Steve's Xenix ranlib in the comp.sources.misc archives -- it doesn't choke on long identifiers the way SCO's does -- essential for G++ users. Again, what's to stop people using the programs they can get for purposes other than the intended ones ? So I think you *gotta* admit that you *can* get enough of a development system for free. Perhaps someone ought to sit down and integrate this whole thing -- I haven't time. Anyway, the very idea of a Unix without compiler is ridiculous. But then, so's the idea of Unix without source. Comments, Mr. Fagan ? :-) -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
pgd@bbt.se (01/01/91)
In article <1990Dec31.005602.7520@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >Someone once posted a Xenix system call library, and there's Earl Chew's >stdio, and lots of fragments to replace most of the unix libc.a >scattered about the net (especially in the BSD directory on uunet :-) And don't you get /shlib/libc_s with the base system? Quite a lot of the system library is there. You only need a x.out to coff converter, to use it. I might post such a one, if anyone is interested. I have not checked, but don't you need the c-compiler to compiler c.c in the link kit? If so, you have everything in the base system. I used to use gcc with the gnu loader, and my system call library, before the gnu OMF kit was out. But sometimes i regret that I changed, and did not make an OMF to a.out converter instead. Especially when I discovered that the Microsoft linker does not correctly link up jumps to absolute addresses, I became quite fried with it. ld also outputs wrong code when used with the GDB debugger. Especially when the load module reaches 1MB size. The linker just scrambles the segment table, and the segment image... Try using GDB for something big, and you will get the surprise. >So I think you *gotta* admit that you *can* get enough of a development >system for free. Perhaps someone ought to sit down and integrate this >whole thing -- I haven't time. Anyway, the very idea of a Unix without >compiler is ridiculous. But then, so's the idea of Unix without source. I agree fully. I have never so far used a computer for which one of the first programs needed is not a disassembler -- just to figure out the arguments to the undocumented system calls, or something else "legal". (On the first operating system i encountered, all system calls were undocumented :-( ).
ronald@robobar.co.uk (Ronald S H Khoo) (01/02/91)
pgd@bbt.se writes: > And don't you get /shlib/libc_s with the base system? You do. > You only need a x.out to coff converter, > to use it. I don't see what you mean... 1) you don't get /lib/libc_s.a, (can you regenerate that from /shlib/libc_s ? I have no idea how COFF shared libraries work) 2) Xenix /bin/ld doesn't understand COFF anyway. So how do you go about using it ? If there is a way, more detail please! > I have not checked, but don't you need the c-compiler to compiler c.c > in the link kit? No, there's no equivalent of idcomp. The Xenix kernel configuration tables are in *assembler* (config can generate either assembler *or* C -- using C is better because stuff goes into BSS in C but DATA with assembler don't ask me why) and the limited assembler provided (/usr/lib/storel I think) is invoked to assemble them by the /usr/sys/conf/configure program. I have no idea what the limitations of storel are, I have never used it for anything other than configuring kernels :-) So you are stuck with having to get gcc, but it's worth it anyway. > I used to use gcc with the gnu loader, and my system call library, > before the gnu OMF kit was out. Really ? What executable file format did you use, and what conversion program did you use to generate it ? > Try using GDB > for something big, and you will get the surprise. Big programs are the work of the devil -- all programs should fit in 64k + 64k :-) :-) :-) Seriously though, this does mean that perhaps the way forward is to go back to using your original technique of using GNU ld, and convert the OMF libraries to a.out ones ? Maybe we really ought to make the effort to put together a complete libc.a so we can completely forget the SCO stuff. > (On the first operating system i encountered, all system calls were > undocumented :-( ). Actually, I'd say that's true on Xenix as well. Can you think of anything more stupid than the SCO manual sections ? *everything* is in "S" section so no one knows what's a system call and what's not. At least in SCO Unix you can find out from /usr/include/sys.s -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
sef@kithrup.COM (Sean Eric Fagan) (01/02/91)
In article <1991Jan1.234509.3207@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >Actually, I'd say that's true on Xenix as well. Can you think of anything >more stupid than the SCO manual sections ? *everything* is in "S" section >so no one knows what's a system call and what's not. Well... what's a system call in this release won't necessarily be a system call in the next release. Take chsize(). In xenix, it's a system call. In unix (3.2, that is), it's still honored as a system call, but most people would not be able to tell the difference if it were replaced (in the COFF library) with a routine that only called fcntl. Why would you want to do this? Because it's nicer to put things in user code (no context switching, then, which is horrible), and it might be more efficient that way. Note that there are also some disadvantages of that, mostly that, if your code is buggy, you can fix a system call by mereley installing a new kernel, while you need to compile everything that includes the routine otherwise. Anyway, just me rambling on a bit 8-). -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
pgd@bbt.se (01/03/91)
In article <1991Jan1.234509.3207@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: I wrote: >> You only need a x.out to coff converter, >> to use it. > >I don't see what you mean... > > 1) you don't get /lib/libc_s.a, (can you regenerate that from > /shlib/libc_s ? I have no idea how COFF shared libraries work) > > 2) Xenix /bin/ld doesn't understand COFF anyway. > >So how do you go about using it ? If there is a way, more detail please! > I did not even know I was missing /lib/libc_s.a, or what it contains... Today I was trying to get it to work, since I said it does. I have a printf("hello") program, and the only missing routines, from the link, are Scrt0, start, exit, and cleanup. The problem is start, which has to make special initialization for the shared library. This means that libc_s is giving the core of libc.a To get the xenix kernel to load the library, I use a program which converts the executable x.out file, to an executable coff file, and puts in the information to load the library in it. That part works nicely. To link with /shlib/libc_s, i did a "nm" on it, and hand-converted the output to an assembler file, to get the jump addresses for the routines. A COFF shared library is just a normal COFF file, which is almost identical to a x.out file. Everything is just on different adresses. The load address is on something like 0xa000000 etc. To tell the kernel to load the shared library, there is just an extra "lib" segment, in the segment table, which contains the path of the library file. The rest is automagic. The x.out format could very easily be extended to use shared libraries. Most x.out utilities on xenix, actually work with coff format. ld accepts coff format as input. >> I used to use gcc with the gnu loader, and my system call library, >> before the gnu OMF kit was out. > >Really ? What executable file format did you use, and what conversion >program did you use to generate it ? I hacked GNU ld to produce x.out format. That is not very hard. But next time I will hack it to produce coff format instead, since then we get the sharable libraries also, and maybe, maybe, the patch-files for coff format will do half the work also. > >> (On the first operating system i encountered, all system calls were >> undocumented :-( ). > >Actually, I'd say that's true on Xenix as well. Can you think of anything >more stupid than the SCO manual sections ? *everything* is in "S" section >so no one knows what's a system call and what's not. At least in SCO Unix >you can find out from /usr/include/sys.s The "S" section is really stupid. Is it there to "protect" the user from knowledge about system calls, or what?
sef@kithrup.COM (Sean Eric Fagan) (01/04/91)
In article <1991Jan2.200940.3320@bbt.se> pgd@bbt.se writes: >I did not even know I was missing /lib/libc_s.a, or what it contains... It contains the stubs for the shared library. I am going to try to summarize what I think you've been trying to do, and then I'm going to tell you why you cannot. If I've misunderstood you, please let me know, and I will tell you why you're wrong with the new understanding. You are trying to generate programs that use shared libraries, using only the standard Xenix 2.3.0 devsys. You have noticed that the shared libraries are in /shlib/libc_s, and that an nm of them shows some symbols, which you assume you can jump to. Correct? This is *not* correct. There are two parts to a shared library: the shared part (obviously 8-)), and the non-shared part. The private part, which is mostly contained in libc_s.a (the archive you get with -lc_s) does a few things, such as actually jumping to the correct entry in the jump table. The shared part is, for all intents and purposes, an executable, with references to data and jump tables that are not resolved therein. The jump table of the shared library is rigidly defined: changing it will break any application that uses that part of the library, unless you recompile it. (You can, however, add to the shared library, if you have the definition file, which is not shipped with either xenix or unix.) >I have a printf("hello") program, and the only missing routines, from the link, >are Scrt0, start, exit, and cleanup. The problem is start, which has >to make special initialization for the shared library. This means that >libc_s is giving the core of libc.a Huh? That doesn't parse too well. The shared library has unresolved references to malloc and free, among others. This is so that you can link in your own version of malloc, and all of the routines in the shared library will use it. Please tell me how you managed to resolve these? They won't show up unresolved, because there is no symbol name in the shared library for them; instead, there is a table, which is filled in by the linker, *IF YOU HAVE THE SHARED LIBRARY ARCHIVE*. >To get the xenix kernel to load the library, I use a program which >converts the executable x.out file, to an executable coff file, and >puts in the information to load the library in it. That part works >nicely. *No*. That part only *appears* to work nicely. In reality, it is doing something very strange, and bizarre, and not terribly useful. >Most x.out utilities on xenix, actually work with coff format. ld >accepts coff format as input. And generates x.out stuff. It calls a cvtcoff program, I believe, which converts the COFF to OMF, and then links. Although it is possible to reverse engineer the stuff necessary for a shared library, it does not sound as if you have done it. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
pgd@bbt.se (01/06/91)
In article <1991Jan04.045614.13386@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >I am going to try to summarize what I think you've been trying to do, and >then I'm going to tell you why you cannot. If I've misunderstood you, >please let me know, and I will tell you why you're wrong with the new >understanding. Ok, go ahead. >You are trying to generate programs that use shared libraries, using only >the standard Xenix 2.3.0 devsys. You have noticed that the shared libraries >are in /shlib/libc_s, and that an nm of them shows some symbols, which you >assume you can jump to. > >Correct? Correct. I have also verified that you actually can jump to them. >The shared library has unresolved references to malloc and free, among >others. This is so that you can link in your own version of malloc, and all >of the routines in the shared library will use it. Please tell me how you >managed to resolve these? They won't show up unresolved, because there is >no symbol name in the shared library for them; instead, there is a table, >which is filled in by the linker, *IF YOU HAVE THE SHARED LIBRARY ARCHIVE*. I doubt very much that these values are filled in by the linker, since they have to be filled in at run-time. I fill them in in start.c, which is probably what the original version also does. > >>To get the xenix kernel to load the library, I use a program which >>converts the executable x.out file, to an executable coff file, and >>puts in the information to load the library in it. That part works >>nicely. > >*No*. That part only *appears* to work nicely. In reality, it is doing >something very strange, and bizarre, and not terribly useful. Well, if it works, who cares if it does something strange, or not? :-) Seriously, the program converts a x.out image to a coff image. You might think that the need for this is bizarre, and I agree. But considering the -unix switch to 'cc', it seem to be exactly what SCO does on their UNIX system. Besides, shared libraries are very useful, if you want to run X-windows, and have a small amount of memory. >Although it is possible to reverse engineer the stuff necessary for a shared >library, it does not sound as if you have done it. I am sorry to disappoint you, but that is exactly what I have done. P Garbha ------------- Any opinions expressed are my own, and generally unpopular with others. -- Sean Eric Fagan
schenk@fsd.cpsc.ucalgary.ca (Eric Schenk) (01/07/91)
In article <1991Jan6.095033.3709@bbt.se> pgd@bbt.se writes: >Seriously, the program converts a x.out image to a coff image. You >might think that the need for this is bizarre, and I agree. But >considering the -unix switch to 'cc', it seem to be exactly what SCO >does on their UNIX system. > >Besides, shared libraries are very useful, if you want to run >X-windows, and have a small amount of memory. On this note I'd like to add a question to the discussion. Does anyone out there have the necessary tools to create new shared libraries on Xenix, and of course to compile and link programs which use them? In particular I'd like to do this using gcc. I am not really interested in reverse enginering sh_lib.c, just in constructing new shared libraries for use in my programs. If no one has done this can someone point me to the necessary coff documentation so I can consider doing it myself. (BTW, I've noticed that the include files mention a limit of 2 shared libaries per process in xenix. Is this limit hard, or can it be changed?) ------------------------------------------------------------------------------- Eric Schenk Department of Computer Science, University of Calgary schenk@cpsc.ucalgary.ca Just another graduate slave. -------------------------------------------------------------------------------
ronald@robobar.co.uk (Ronald S H Khoo) (01/07/91)
pgd@bbt.se writes: > [ sef@kithrup.com wrote ] > >Although it is possible to reverse engineer the stuff necessary for a shared > >library, it does not sound as if you have done it. > I am sorry to disappoint you, but that is exactly what I have > done. Are you going to share this with us ? If whoever it is that promised us a X server for Xenix fulfils his promise, this sounds like a *brilliant* way to run X with Xenix. And without having to buy the development system too! Wow. Sounds good to me if it's true! But I remember that you said something about SCO's linker not coping with the absolute jumps. How did you work around that problem ? (Sean, would you be prepared to look at and help shake down pgd's work if he makes it available ?) -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
pgd@bbt.se (01/08/91)
In article <1991Jan6.171120.9314@cpsc.ucalgary.ca> schenk@fsd.cpsc.ucalgary.ca (Eric Schenk) writes: >On this note I'd like to add a question to the discussion. >Does anyone out there have the necessary tools to create >new shared libraries on Xenix, and of course to compile and >link programs which use them? In particular I'd like to do this >using gcc. I am not really interested in reverse enginering sh_lib.c, >just in constructing new shared libraries for use in my programs. I am not really interested in shlib_c either, that is a side track. But the same tools can be used to make new shared libraries, that is the interesting part. Currently they are a little bit disintregated, through, and require some work. >(BTW, I've noticed that the include files mention a limit of 2 shared >libaries per process in xenix. Is this limit hard, or can it be changed?) No, unless you have the complete sources. The limit is hard-wired in the user structure, which means you have to recompile more or less everything to change it. (which means most kernel modules, probably also ps, adb, sdb, gdb, etc.) You are obviously not supposed to use shared libraries on xenix.
pgd@bbt.se (01/08/91)
In article <1991Jan7.102336.8266@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >But I remember that you said something about SCO's linker not coping with >the absolute jumps. How did you work around that problem ? If the absolute jumps cannot be made/figured out, i will use indirect jumps, and instead of a jump table, have an address table. >(Sean, would you be prepared to look at and help shake down pgd's work > if he makes it available ?) I am going to make it available as soon as everything is working nicely.