Return-Path: pg_adm@postgres.berkeley.edu Received: by postgres.Berkeley.EDU (5.61/1.29) id AA00401; Tue, 11 Feb 92 15:43:10 -0800 Message-Id: <9202112343.AA00401@postgres.Berkeley.EDU> From: U-E99999-Stephen Williams Subject: postgres on SCO Unix (fwd) To: postgres@postgres.berkeley.edu Sender: pg_adm@postgres.berkeley.edu To: postgres@postgres.berkeley.edu Date: Tue, 11 Feb 92 14:34:25 EST Mailer: Elm [revision: 64.9] Again, I have a Sys V 3.2 (ISC) port mostly done. There are a few bugs left, but the backend works completely. I am still having trouble with the postmaster starting and communicating to the backend correctly. Although I plan on commercializing an aggregation of Postgres and my application building tools (screen/menu/form builder, data dictionary, and 4GL (very object oriented)), I have decided to release my patches to the Postgres project. I will do this shortly (I just had a baby, got a new full time position, started another company, had an operation etc.). (I did correspond with the software office at Berkeley and gave them an automatic Educational License to any derivative of Postgres, as the Postgres documents state.) I can comment an a few of the following from memory: > First: I had to create a modified version of GNU Make. The SysV make and GNU Make by default had trouble feeding large command lines to the shell, apparently based on a kernel argv buffer limit. I used pipe or something similar. I still have death of child problems, which are ignorable. > > Well I found out that Gen_creator.sh creates all the Make... and RMake... > functions I was missing so I got left with only 6 problems. I had to change the syntax or version of awk (I don't remember which) to get this to work. > > 1) The file storage/lmgr/proc.c uses setitimer which is not available on > SCO unix so I used alarm instead. Sounds fine, or even ignore the timers altogether (the ones for performance reporting). > > 2) Files heap/hrnd.c and nobtree/nobtree.c uses the function random so I > used SCO's rand instead. check. > > 3) File tcop/postgres.c uses getwd. I assume this gets the current working > directory so I used getcwd. check. Also, the SysV chdir() has an interesting difference from Berkeley: chdir("") is an illegal directory. I replaced every call with a trinary like: chdir(arg == "" ? "." : arg); > > 4) File tcop/postgres.c uses getrusage but I cant find this in SCO's libraries > although struct rusage is defined in sys/resource.h. Can someone send me > the manual page for this so I could work out some alternative. This was for performance monitoring. I think there is a 386 monitor program available, but I don't have it. I just ifdefed everything till later. > > 5) File utils/adt/float.c uses the fuction cbrt. I assume this is a cube > root function so I have implemented this with the function pow. check, not even sure I finished this.... > > 6) Now for the difficult bit. Can someone tell me what the funtions > dynamic_file_loader and dynamic_load do. Looking at port/seq/dynloader.c > I see that ld is called with a load of options which are not avaiable > on SCO. eg > > ld -N -x -A SYMBOL_TABLE -T ADDR > For SysV 3.2 (I assume also for SCO Unix, not Xenix), the linker is very intelligent and can take a description file. You just link with a proper description file telling where to load in memory. It's a little complicated to explain everything here. I still have to write the code that walks the symbol table, but the coff code in SysV or in GNU gas/gdb should make that easy. > Could someone explain what these options do. > > I would welcome any comments on these points. > > I have spent about a week on this now and it would appear that a SystemV > port is fairly easy. I wondered if the Group was considering makeing > SysV rel 3 an official port as this would make Postgres available to a much > bigger audiance. > -- I made many other changes, mostly berkelyisms, to all parts of the code. I spent about a month part-time. I would also like to merge V.3.2 into the master. One problem will be that about 8 files have names > 14 chars and must be changed for everyone. > regards trevor > ------------------------------------------------------------------------------ > Trevor Harris UUCP: trevor@trevan.uucp > Trevan Designs Limited > 5 Blackwater Close, Ash, > Aldershot, Hants, UK. > GU12 6JS > Let me know what you think.... Oh, BTW, use sdw@world.std.com in the future as I will be vacating this address. Thanks. sdw -- Stephen D. Williams SDW Systems (513) 496-5223 Pager (513) 439-5428 VMail Object Oriented R&D Internet: sdw@world.std.com CIS 76244.210@compuserve.com Source Distribution By Horse: 10028 Village Tree Ct., Miamisburg, OH 45342 GNU Support ICBM: 39 34N 85 15W