Re: Informix Online: Shared Memory Problem (Linux)

Neal Howard (neal@fohnix.metronet.com) wrote: : The problem is a bug in the "ipc.c" portion of the iBCS module. : Get the April '95 version of iBCS-1.2x and get the patch file : (something-or-other).patch1 from tsx-11.mit.edu. You'll probably : have to apply the patch by hand to the ipc.c source code file . . . [...] Got this update to iBCS and applied the patch by hand and it did in fact solve the problem. I'm currently running OnLine (Version 5.01.UD2) just fine. : Use at least kernel version 1.2.10, preferably 1.2.11 and you'll be : pleasantly surprised with the results (after you install the compiled : iBCS module). Using kernel v1.2.10, and it seems to do just fine. : You'd probably have to use cooked filespace chunks, I have no idea if raw : character device diskspace would work under Linux or not. I'm currently using a cooked file, simply because I don't have a spare partition to give to OnLine at the moment. I too am curious if OnLine will get confused by Linux's lack of raw devices. : Also, you probably won't be able to make any "C" compiler 4gl : or ESQL/C apps since the link phase would attempt to link : your compiled-natively-for-Linux applications objects to : compiled-natively-for-SCO Informix library stuff, and the linker would : most certainly bitch about that. I've been contemplating this issue some myself. The easiest "solution" to this difficulty is building compiled executables on another non-Linux machine. Of course this isn't that satisfying a solution. Another alternative would be to have a Linux machine use the C compiler, linker, assember, headers, and libraries from a COFF compliant machine. Only problem would be how (if at all) could that be done with gcc installed too? A third idea was to keep a seperate installation of Linux on the machine with the COFF compiler, and no gcc, just for building COFF binaries--again a not so satisfying solution. : I also don't know much about the internals of the RDS version of : 4gl, but if it doesn't use gcc and Linux's ld, then it might work if : it compiles to its p-code and links its objects and libraries with : a proprietary compiler & linker, provided that the RDS's compiler, : linker, and fglgo p-code runner all will run okay under iBCS. I'm using RDS and the Debugger and they work just fine. Since the output from the r4gl compiler is just p-code it doesn't have the same problems as trying to build COFF binaries like would be involved with i4GL or ESQL/C. The p-code programs are run by a COFF program same as you would use sperform to run Perform screens. One major problem I had was trying to get Dave Snyder's db4glgen program to work. Since it requires it's own special C-functions and builds a new 4gl runner and debugger module. I had to punt on this one and build the new runner and debugger on an ISC machine and then ship the binaries back. I now use these new COFF executables all the time instead of the original fglgo and fgldb programs. For the moment, it helps quite a bit to have access to a non-Linux machine that can produce some COFF binaries as needed. -- +--------------------+----------------------------+--------------------------+ | Michael Faurot | mfaurot@phzzzt.atww.org | I don't like | | ------- ------ | | lima beans!! | +--------------------+----------------------------+--------------------------+