Trying to build a library that uses some ESQL generated code

Hi I'm having trouble linking a function from an esql/c file into the rest of my library; I *thought* everything was going well, the compilation and linking seem to happen (outside of esql) however the intermediate .c file generated seems to have no code in it; nor does the finished library contain the symbols for the functions I had supposedly compiled. Argh! Can anyone point me at some useful help for doing this kind of thing? I'm seriously considering getting a product like roguewave dbtools.h++ tomorrow; but would like to see a demo at least working using the esql/c compiler. -- Ben Gould

Ben Gould wrote: > > Hi > > I'm having trouble linking a function from an esql/c file into the rest > of my library; I *thought* everything was going well, the compilation OK - mea culpa as far as the empty intermediate .c file - for some reason this was a side effect of running the c preprocessor first. However, I can't seem to get this to specify (now) the libraries that it should be linked to - is there a reference to this anywhere? -- Ben Gould

Just use esql to perform the compiling and linking NOT just the translation from ESQL to C. It KNOWS what libraries to link. If you are going to be stubborn and insist on running ld yourself, believe me very few of us do (I'll expain why shortly) the later versions of esql have and option (-libs) that will output a list of -l options you need to include with your ld command line. The main reason for using esql to generate the .o files and to link then into ANY executable is that Informix has always felt free to move objects from library to library, create new libraries and drop others from one release to another, and move libraries from one sub-directory to another. If you maintain your makefiles and compile/link scripts yourself to use cc/gcc and ld instead of esql to compile and link you will have to revisit them everytime you upgrade your ESQL version. The esql script is a fine compiler and linker driver, use it. In addition, esql knows what libraries to use for multi-threaded versus single threaded applications, for shared versus static links etc. Art S. Kagel Ben Gould wrote: > > Ben Gould wrote: > > > > Hi > > > > I'm having trouble linking a function from an esql/c file into the rest > > of my library; I *thought* everything was going well, the compilation > > OK - mea culpa as far as the empty intermediate .c file - for some > reason this was a side effect of running the c preprocessor first. > > However, I can't seem to get this to specify (now) the libraries that it > should be linked to - is there a reference to this anywhere? > > -- > Ben Gould

"Art S. Kagel" wrote: > > Just use esql to perform the compiling and linking NOT just the translation from > ESQL to C. It KNOWS what libraries to link. If you are > going to be stubborn and insist on running ld yourself, believe me very > few of us do (I'll expain why shortly) the later versions of esql have and > option (-libs) that will output a list of -l options you need to include > with your ld command line. > > The main reason for using esql to generate the .o files and to link then > into ANY executable is that Informix has always felt free to move objects > from library to library, create new libraries and drop others from one > release to another, and move libraries from one sub-directory to another. > If you maintain your makefiles and compile/link scripts yourself to use > cc/gcc and ld instead of esql to compile and link you will have to revisit > them everytime you upgrade your ESQL version. The esql script is a fine > compiler and linker driver, use it. > > In addition, esql knows what libraries to use for multi-threaded versus > single threaded applications, for shared versus static links etc. Hi Having got all this to "work" now I'm having problems trying to share connections (ontlitcp based) between many different threads. It seems to perform OK if the connection is opened, queries are executed and the connection is closed *all within an application global mutex*. I don't like this, but can live with it as long as I can work around the following latency problem: Although the tcp connections between my client and the informix server seem to be reused by the ontlitcp connection libraries; informix sessions are being created and destroyed each time I "connect". This is causing a huge (and totally unacceptable) performance hit on the server. Trying to create named connections for later reuse (possibly on a different thread - I can't control this) seems to cause arbitrary deadlocks outside my mutex; and sometimes it won't pick up the previously named connection. I'm sure the deadlocks aren't happening inside my code because the mutex around all the database routines works without deadlocking when I connect-execute-disconnect. So I suspect its a problem with the way I'm using the informix libraries in this environment. Can anyone suggest (and please suggest anything) third party connection libraries that will allow . full mt-safe compliance; compilation with solaris native threads support . connection sharing / pooling (whether manually or automatically) . me to continue developing this C based plugin without too much redesign up front... Target platform - Solaris 2.6 I'm going to phone roguewave when the US wakes up for a evaluation of dbtools.h++; I'd appreciate any comments from anyone who's used this... Thanks in advance. -- Ben Gould