Re: Unresolved functions compiling 4GL and ESQL/C programs
Posted in 1999
Topics: Connectivity: ESQL/C, 4GL & Embedded SQL
Jonathan Leffler wrote in message <37551154.5289@earthlink.net>... >Carl Wu wrote: >> Art S. Kagel wrote in message <3753F7C7.CFCA2E3A@bloomberg.net>... >> >Carl Wu wrote: >> >> When compiling a program consists of some 4GL modules and some >> >> ESQL/C modules and some C modules I got the following error >> >> message at the linking stage. >> >[SNIP] >> >> [SNIP] >> >Just use c4gl to do ALL compiling and linking! It will handle >> >everything properly if you let it. So for esql modules use c4gl -c. >> >For 4GL modules use c4gl -c. For C modules to be linked with 4GL use >> >c4gl -c. Even for assembler modules (.a) to be linked with 4GL use >> >c4gl -c. Then to link use c4gl -o passing the objects and your >> >libraries. This works best. >> > >> >[SNIP] >> >> Thanks very much! >> I got my program compiled and linked, not until I used "c4gl -c" to >> recompile all my library sources and regenerate the library ( "*.a" >> static library. There are some ESQL/C and C modules in the library). >> >> Another question: We got some programs consist of only ESQL/C >> modules and they need to link with the library. So for those ones >> should I use "c4gl" or "esql" to do the compile and linking? > >Use the ESQL/C compiler for code which is going to be used in a pure >ESQL/C program. Use the C4GL compiler for code which is going into >an I4GL program. > The situation is: the ESQL/C code in the library is used by both pure ESQL/C programs and 4GL programs. Now, for the 4GL programs' sake, I have used c4gl to compile the library. I'm feeling a bit of uncomfortable if I use "esql" to compile the local modules of the pure ESQL/C programs and use "esql" to link them with the "c4gl"_compiled library (should I be worry?) . The following two solutions sound good to me: 1. use "c4gl" to do every compiling and linking, forget about ESQL/C or 4GL. 2. generate two versions of library, one use "c4gl" to compile, to be used with 4GL programs, the other use "esql" to compile, to be used with ESQL/C programs. Can any one point out advantages/disavantages of these? Or give warning of potential problems if there is any. Thanks in advance. >> I tested on one of my ESQL/C programs both "c4gl" and "esql" worked. > >Yes. Which was larger? The esql compiled and linked binary was larger. Remember the library was compiled by c4gl. Should I use c4gl in this case because the binary was smaller? Thanks! [SNIP] >Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) >Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN >#include <disclaimer.h> >
I'm going to jump in here again and suggest that you avoid all of these problems by making a separate library for "pure" ESQL/C to use. You may want to break the pure "C" modules to a third library that can be shared by both C4GL and ESQL/C programs while any ESQL/C modules that are to be used by both C4GL programs and ESQL/C programs would be compiled separately by both c4gl and esql and the appropriate object file loaded into the appropriate library. Thus if module utils.ec is used by both 4gl and esql/c progs the makefile might contain: libecc4gl.a: .... utils_4gl.o libecesql.a: .... utils_esql.o utils_4gl.o: utils.ec ... c4gl -c utils.ec mv utils.o utils_4gl.o utils_esql.o: utils.ec ... esql -c utils.ec mv utils.o utils_esql.o Art S. Kagel Carl Wu wrote: > > Jonathan Leffler wrote in message <37551154.5289@earthlink.net>... > >Carl Wu wrote: > >> Art S. Kagel wrote in message <3753F7C7.CFCA2E3A@bloomberg.net>... > >> >Carl Wu wrote: > >> >> When compiling a program consists of some 4GL modules and some > >> >> ESQL/C modules and some C modules I got the following error > >> >> message at the linking stage. > >> >[SNIP] > >> >> [SNIP] > >> >Just use c4gl to do ALL compiling and linking! It will handle > >> >everything properly if you let it. So for esql modules use c4gl -c. > >> >For 4GL modules use c4gl -c. For C modules to be linked with 4GL use > >> >c4gl -c. Even for assembler modules (.a) to be linked with 4GL use > >> >c4gl -c. Then to link use c4gl -o passing the objects and your > >> >libraries. This works best. > >> > > >> >[SNIP] > >> > >> Thanks very much! > >> I got my program compiled and linked, not until I used "c4gl -c" to > >> recompile all my library sources and regenerate the library ( "*.a" > >> static library. There are some ESQL/C and C modules in the library). > >> > >> Another question: We got some programs consist of only ESQL/C > >> modules and they need to link with the library. So for those ones > >> should I use "c4gl" or "esql" to do the compile and linking? > > > >Use the ESQL/C compiler for code which is going to be used in a pure > >ESQL/C program. Use the C4GL compiler for code which is going into > >an I4GL program. > > > > The situation is: the ESQL/C code in the library is used by both pure ESQL/C > programs and 4GL programs. Now, for the 4GL programs' sake, I have used c4gl > to compile the library. I'm feeling a bit of uncomfortable if I use "esql" > to compile the local modules of the pure ESQL/C programs and use "esql" to > link them with the "c4gl"_compiled library (should I be worry?) . The > following two solutions sound good to me: > 1. use "c4gl" to do every compiling and linking, forget about ESQL/C or 4GL. > 2. generate two versions of library, > one use "c4gl" to compile, to be used with 4GL programs, > the other use "esql" to compile, to be used with ESQL/C programs. > > Can any one point out advantages/disavantages of these? Or give warning of > potential problems if there is any. Thanks in advance. > > >> I tested on one of my ESQL/C programs both "c4gl" and "esql" worked. > > > >Yes. Which was larger? > > The esql compiled and linked binary was larger. Remember the library was > compiled by c4gl. Should I use c4gl in this case because the binary was > smaller? > > Thanks! > > [SNIP] > > >Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) > >Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN > >#include <disclaimer.h> > >