jlin@weber.ucsd.edu (Jin-Lung Lin) (02/18/91)
Several days ago, I post a query about porting toolpack to HP-UX. Dik replied the following mail, which I consinder as very valuable information. So, after getting his permission, I repost it in the hope of stimulating further discussion. Toolpack seems to be such a wonderful tools that I, like others, try to make it work. Henry Lin jlin@weber.ucsd.edu In article <4781@network.ucsd.edu> you write: > > Hi, has anyone out there succeed in porting the toolpack to HP-UX ? > I got a copy of the source, changed the toolpackpath, typed make and it > went well until the step of linking. A lot of unsatisfied code. It > looks like that f77 can not link the object code generated by cc. Yes, that is one of those problems. The Fortran/C interface is abysmal. It will work on some generic Unix platforms, but not on many others. You have to check out for: 1. Toolpack assumes that a C function called from Fortran must have as name the Fortran identifer in lower case with a underscore appended. You found that is not true on HP (there the C identier is the same as the Fortran identifer; or is it the same in uppercase? I do not remember; both occur in real life). Many more conventions do occur in real life. 2. Toolpack assumes that C pointers have identical format to Fortran addresses. This is not true in general; but I believe this is true on HP. 3. Toolpack assumes that Fortran passes character parameters as two succesive parameters; address and size. This is only one of three methods I have seen. (And the C routines are there to do I/O!) 4. Toolpack assumes that when a program starts up only file descriptors 0, 1 and 2 are open. This may or may not be true; depending on how you call toolpack, what kind of shell you have and how you did login into your system. (On many systems when loggin in through telnet file descriptors 3 and 5 are still open, while when you login through rlogin file descriptor 4 is still open, so some programs will work if you login through rlogin but not when you login through telnet.) And there are still more gripes: 5. Make works fine the first time. Now modify some source file and say make again; it will fail. 6. I wanted to throw away all binaries and looked through the makefile whether it had something like 'make clean' or 'make clear'; sure enough; it had; and blew away all sources! This is all from experience some time ago. I tried to port it to an Alliant (fairly generic Unix in most aspects); I solved 1. to 4. (and had to deal with 5. and 6.); it still does not work. It did take me all over one month using 'adb' to see what was going on; to no avail. So my advise is: if it does not work immediately, drop it. It is a pity because it looks useful. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl