cpcahil@virtech.uucp (Conor P. Cahill) (09/04/90)
In article <1990Sep3.095529.29411@brolga.cc.uq.oz.au> exnirad@brolga.cc.uq.oz.au (Nirad Sharma) writes: >I am running SCO XENIX 2.3.2 ('386 version) and am wondering if some binaries >from an ESIX system will run on my system, more specifically gcc, emacs and >X11R4 as found at 36.102.0.32 (I got the site from an article posted here). Xenix is supposed to be able to run 386 UNIX binaries starting with 2.3. That means that gcc and emacs should run without any problems. However, the X11R4 stuff you found probably has some kernel modifications and/or kernel specific code that will not run under xenix. Note that I used the word probably. I haven't tried it but I do not expect it to work. >Furthermore, could someone please explain whose binaries run on whose 386-UNIXs? 286 & 386 Coff binaries will compile under all 386 Unix systems (ESIX, Interactive, SCO UNIX, Intel UNIX, etc) and SCO Xenix >= 2.3. 286 & 386 Xenix binaries will run under all 386 Unix systems that are based upon At&t unix >= 3.2. This includes all ESIX releases, Interactive Unix releases >= 2.0, all Sco Unix releases, Intel/Bell Tech Unix releases >= 3.2. IMPORTANT NOTE: While the binaries will execute, the code may call some system specific routines (especially if they do wierd stuff with the console keyboard or display) or may expect some system specific files to be in a different place. This means that while they will execute, they may not work. 2ND IMPORTANT NOTE: While you can run Xenix executables on UNIX and vice-versa, you cannot use the standard debugging tools to view core files generated from executables for the other system. You will also have a problem reading Xenix libraries on Unix systems and probably vice-versa. By "reading" I mean using them to link with a program. This important note does not apply to SCO UNIX, since it has the Xenix compiler and development tools. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
palowoda@fiver (Bob Palowoda) (09/04/90)
From article <1990Sep04.000727.17429@virtech.uucp>, by cpcahil@virtech.uucp (Conor P. Cahill): Hmm, > 2ND IMPORTANT NOTE: While you can run Xenix executables on UNIX and > vice-versa, you cannot use the standard debugging tools to view core > files generated from executables for the other system. You will also > have a problem reading Xenix libraries on Unix systems and probably ^^^^^^^^^^^^^^^^^ Just curious are there tools to create lib files on SCO UNIX that other 386 versions of UNIX will read. Or is this standard when you use 'rcc'. Also is there a obj file conversion program to move to coff? With respect to debugging the corefile. I would assume that developers distributing object files for other 386 version of UNIX would do so in COFF format and therefor would have the problem with linking and useing other 386 debugging tools. Or did I miss the boat somewhere? > vice-versa. By "reading" I mean using them to link with a program. This > important note does not apply to SCO UNIX, since it has the Xenix compiler > and development tools. I don't understand why someone would want to do that anyways? ---Bob -- Bob Palowoda palowoda@fiver | *Home of Fiver BBS* Home {sun}!ys2!fiver!palowoda | 415-623-8809 1200/2400 {pacbell}!indetech!fiver!palowoda | An XBBS System Work {sun,pyramid,decwrl}!megatest!palowoda| 415-623-8806 1200/2400/19.2k TB+
cpcahil@virtech.uucp (Conor P. Cahill) (09/04/90)
In article <1990Sep4.013116.21214@fiver> palowoda@fiver (Bob Palowoda) writes: > With respect to debugging the corefile. I would assume that developers >distributing object files for other 386 version of UNIX would do so in >COFF format and therefor would have the problem with linking and useing >other 386 debugging tools. Or did I miss the boat somewhere? This should be true, but it depends upon the manufacturer. >> vice-versa. By "reading" I mean using them to link with a program. This >> important note does not apply to SCO UNIX, since it has the Xenix compiler >> and development tools. > > I don't understand why someone would want to do that anyways? Last year we purchased a copy of the UNIFY/Accell development system for Interactive Unix. Unify had done a port to Xenix System V/386 and when one of the marketers there read the UNIX 3.2 release notes that said something like "This release includes full compatability with Xenix..." the marketers decided to release the Xenix product for Interactive Unix. The problem with this is that the C interface libraries did not work (i.e. I couldn't compile a C program that used the database). What I did to get around this was to load our dusty xenix 2.3.2 diskettes onto a sub-directory of our 386/ix system, chroot to that directory and compile the database applications. However, when my code dropped core, the xenix debugging utilities couldn't read the interactive core file and the interactive debugging utilities couldnt read the xenix binaries. So it was back to the age old (and slow) debugging process of adding printfs through the code to find where it was breaking. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
palowoda@fiver (Bob Palowoda) (09/05/90)
From article <1990Sep04.125013.21424@virtech.uucp>, by cpcahil@virtech.uucp (Conor P. Cahill): [to answer the question of why would anyone want to link Xenix obj's to unix] > Last year we purchased a copy of the UNIFY/Accell development system for > Interactive Unix. Unify had done a port to Xenix System V/386 and when > one of the marketers there read the UNIX 3.2 release notes that said something > like "This release includes full compatability with Xenix..." the marketers > decided to release the Xenix product for Interactive Unix. > > The problem with this is that the C interface libraries did not work (i.e. > I couldn't compile a C program that used the database). Uggh! I can't beleive UNIFY would do something like this without testing the product. Actually if they did they must have produced nothing but "no sales", which inturn cost UNIFY and the customers money. > What I did to get around this was to load our dusty xenix 2.3.2 diskettes > onto a sub-directory of our 386/ix system, chroot to that directory and > compile the database applications. However, when my code dropped core, > the xenix debugging utilities couldn't read the interactive core file and the > interactive debugging utilities couldnt read the xenix binaries. Actually I tried the same thing with Informix and had about the same results. What I would really like to see is some sort of OMF <-> COFF conversion utility. Or should I say "conversion/tranlation" utility. Or maybe "conversion/translation/bugfilter" utility. The point is Xenix will eventually die off, nobody will want to spend the time doing ifdefs if they had the tool to do the conversion. I'm not an expert on compiliers, maybe some of the compiler guru's out there can comment if this can be done. ---Bob > back to the age old (and slow) debugging process of adding printfs through > the code to find where it was breaking. I sometimes wonder if this was the inspiration of vi's macro's. ---Bob -- Bob Palowoda palowoda@fiver | *Home of Fiver BBS* Home {sun}!ys2!fiver!palowoda | 415-623-8809 1200/2400 {pacbell}!indetech!fiver!palowoda | An XBBS System Work {sun,pyramid,decwrl}!megatest!palowoda| 415-623-8806 1200/2400/19.2k TB+
tin@smsc.sony.com (Tin Le) (09/07/90)
In article <1990Sep5.095656.12778@fiver> palowoda@fiver (Bob Palowoda) writes: > Actually I tried the same thing with Informix and had about the same results. >What I would really like to see is some sort of OMF <-> COFF conversion >utility. Or should I say "conversion/tranlation" utility. Or maybe >"conversion/translation/bugfilter" utility. The point is Xenix will ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ There are, they have been there in ISC since v1.0.6 (maybe even earlier). I don't remember the exact names now, my manuals are at home, but I believe it is called "conv" or "omf"... It has been a couple of years since I last used it. >eventually die off, nobody will want to spend the time doing ifdefs if >they had the tool to do the conversion. I'm not an expert on compiliers, >maybe some of the compiler guru's out there can comment if this can >be done. > -- Tin Le -- . --------------------------------------------------------------- . tin@smsc.sony.com | {uunet,mips}!sonyusa!tin . (408) 944-4157