timo@cwi.nl (Timo Krijnen) (01/03/91)
We are a little late in responding to the problems that arose around the posting of the ABC distribution for Unix machines to comp.sources.unix because our institute was closed between Christmas and NewYear. Apologies. 1) Missing files. Aparently somewhere 11 files got lost, either between us and the moderator or further up the path. That accounts for all those complaints by the linker. 2) Setup and Unixes. Setup tries to find out what type of Unix you are running. After it was written (years ago:-) most unixes got "enhanced". Some SystemV-look-alikes added BSD-isms and vice versa. We have a new version which no longer uses SIGCLD and SIGCHLD, but instead tries to discriminate between BSD-types with SIGXCPU and VTALRM and checks for System V with SIGPWR. But it uses this only as a suggestion, leaving the ultimate choice to the installer herself. 3) getwd() versus getcwd(). Oops, we "fixed" that for System V without testing it, because we did not have any System V machines at the time. 4) compound() and remove() These are private routines, whose names were invented before they turned up in standard header files or libraries (like compound() on Sparcs and remove() in System V). The fixes are quite easy: add e.g. "#define compound b_compound" to an apropriate header file (ihdrs/i2par.h in this case). We are busy producing a posting to fix al these problems. I have send a mail to Rich Salz asking him to accept our fixes as a "definite" patch; otherwise we will post to comp.sources.bugs in a week or so. Groetjes, timo krijnen (timo@cwi.nl) PS. There indeed does exist a mailing list for ABC: abc-list@cwi.nl; send mail to abc-list-request@cwi.nl to join it. -- Timo Krijnen CWI (Center for Math. & Comp. Science), Amsterdam timo@cwi.nl
craig@attcan.UUCP (Craig Campbell) (01/04/91)
In article <2747@charon.cwi.nl> timo@cwi.nl (Timo Krijnen) writes: >2) Setup and Unixes. >Setup tries to find out what type of Unix you are running. After it >was written (years ago:-) most unixes got "enhanced". Some >SystemV-look-alikes added BSD-isms and vice versa. We have a new >version which no longer uses SIGCLD and SIGCHLD, but instead tries to >discriminate between BSD-types with SIGXCPU and VTALRM and checks for >System V with SIGPWR. But it uses this only as a suggestion, leaving >the ultimate choice to the installer herself. >-- > Timo Krijnen > CWI (Center for Math. & Comp. Science), Amsterdam > timo@cwi.nl Timo, there is what might be considered a better way to determine what type of system a given package is being compiled on. That is, the reserved defined symbols in cpp(1). For example: System Symbols Defined By cpp(1) AT&T 3B2 unix u3b2 AT&T 3B5 unix u3b5 AT&T 6386 unix i386 AT&T 6486 unix i386 (Oh well, it's still in CI) etc.... I beleive most (hopefully all) vendors have defines for their unique systems in their cpp(1) program. I do not have available other vendors systems at this time, however, so I cannot verify that or list the defines. Perhaps other netters could fill you in about these. If these defines are used to select Berkley/Sys V then hopefully, checking include files, which may change, will be unnecessary. Hope this is helpful, (It really does make porting easier...) craig
nicb@ctr@italy.eu.net (Nicola Bernardini) (01/08/91)
In article <13368@vpk4.UUCP> craig@vpk4.ATT.COM (Craig Campbell) writes: >In article <2747@charon.cwi.nl> timo@cwi.nl (Timo Krijnen) writes: > >>2) Setup and Unixes. >>Setup tries to find out what type of Unix you are running. After it >>was written (years ago:-) most unixes got "enhanced". Some >>SystemV-look-alikes added BSD-isms and vice versa. We have a new >>version which no longer uses SIGCLD and SIGCHLD, but instead tries to > > ... etc., etc. > >Timo, there is what might be considered a better way to determine what type of >system a given package is being compiled on. That is, the reserved defined >symbols in cpp(1). For example: > >System Symbols Defined By cpp(1) > >AT&T 3B2 unix u3b2 >AT&T 3B5 unix u3b5 >AT&T 6386 unix i386 >AT&T 6486 unix i386 (Oh well, it's still in CI) > >etc.... > >I beleive most (hopefully all) vendors have defines for their unique >systems in their cpp(1) program. I do not have available other vendors >systems at this time, however, so I cannot verify that or list the defines. >Perhaps other netters could fill you in about these. > >If these defines are used to select Berkley/Sys V then hopefully, checking >include files, which may change, will be unnecessary. I think there is also a standard coming up for manifest defines, is'nt it? things like M_I386 on a 386 and so on. (A lot of header files tend to want a little bit of everything, like i386, M_I386, SYS_V, SYSV, etc.) ------------------------------------------ Nicola Bernardini - nicb%ctr@italy.eu.net Centro Tempo Reale Villa Strozzi Via Pisana, 77 50143 Firenze I T A L I A Tel. ++3955/702444 Fax. ++3955/717712 -- ------------------------------------------ Nicola Bernardini - nicb%ctr@italy.eu.net Centro Tempo Reale Villa Strozzi