Linking problems with ESQL/C
Posted in 2000
Topics: SQL Development & Query Writing, Connectivity: ESQL/C, 4GL & Embedded SQL
Hi guys, does anybody know the answer for this problem. We have 3 machines: machine A : development machine B : pre-production machine C : production Machine A: - OS = IRIX64 version 6.5 - ESQLC version 9.21 UC2 - CC MIPSpro compiler version 7.30 Machine B: - OS = IRIX version 6.5 - ESQLC version 9.20 UC1 - CC MIPSpro compiler version 7.20 Machine C: - OS = IRIX64 version 6.4 - ESQLC version 7.2 UC2 - CC MIPSpro compiler 7.12 Why all the three machines are different I don't know but these are the machines we have to work with. Our sourcecode (test.ec) contains a cursor which we prepare first and then declare (with hold) and then we open the cursor. When we pre-compile the sourcecode on machine A and then compile and link it with the MIPSpro compiler then all works fine on machine A. The libraries are linked dynamically. When we FTP the executable to machine B or C then we get an error when we want to fetch the data from the cursor. The error says that we probably closed our cursor. When we use a select statement which returns one variable then all works fine but the moment we make use of a cursor we get this answer. We tried to compile the sourcecode on machine B and C but the error keeps popping up. When we use the -static option and compile the sourcecode without the MIPSpro compiler then the executable can be run on the three machines, but we want to link the libraries dynamically. Does anybody know the answer to this problem or does anybody has an example in which order the libraries have to be linked to the executable. Thank, Hendrie Kain
If you compile with the 9.21 compiler you have to link with the 9.21 libraries and they have to be there on the production machine at runtime. There will always be subtle differences in the libraries of different versions that will cause grief if you mix and match. The fact that a -static linked executable works fine is a dead give away. Install the iConnect product from the SDK disk that was installed on development onto the production machine and voila. Now if you have older execs compiled with earlier compilers and cannot recompile them all then install in a different directory, copy the sqlhosts file there and set LD_LIBRARY_PATH and INFORMIXDIR to the appropriate directory for each class of executable. Art S. Kagel Hendrie wrote: > > Hi guys, > > does anybody know the answer for this problem. > > We have 3 machines: > machine A : development > machine B : pre-production > machine C : production > > Machine A: > - OS = IRIX64 version 6.5 > - ESQLC version 9.21 UC2 > - CC MIPSpro compiler version 7.30 > > Machine B: > - OS = IRIX version 6.5 > - ESQLC version 9.20 UC1 > - CC MIPSpro compiler version 7.20 > > Machine C: > - OS = IRIX64 version 6.4 > - ESQLC version 7.2 UC2 > - CC MIPSpro compiler 7.12 > > Why all the three machines are different I don't know but these are the > machines we have to work with. > > Our sourcecode (test.ec) contains a cursor which we prepare first and then > declare (with hold) and then we open the cursor. > > When we pre-compile the sourcecode on machine A and then compile and link it > with the MIPSpro compiler then all works fine on machine A. The libraries > are linked dynamically. > When we FTP the executable to machine B or C then we get an error when we > want to fetch the data from the cursor. The error says that we probably > closed our cursor. > When we use a select statement which returns one variable then all works > fine but the moment we make use of a cursor we get this answer. > > We tried to compile the sourcecode on machine B and C but the error keeps > popping up. > > When we use the -static option and compile the sourcecode without the > MIPSpro compiler then the executable can be run on the three machines, but > we want to link the libraries dynamically. > > Does anybody know the answer to this problem or does anybody has an example > in which order the libraries have to be linked to the executable. > > Thank, > Hendrie Kain