SHARED OBJECTS/LIBRARIES
Posted in 1995
M> Subject: shared objects/libraries M> Is there anyone out there who has managed to create > shared libraries or/and objects with informix source code ??? A few of us wrestled with the idea recently, and decided on this approach (which only works with C version, alas): 1. Maintain all shared functions in their own .4gl file ("Why?", you say. Read on.). The exception would be if one function is dependant on another function (e.g., shared_dsply_msg calls shared_clr_msg and shared_clr_msg is only used for that purpose. In this case it is acceptable (even good) to put both functions in the same .4gl. 2. Compile each shared .4gl into a .o 3. Use ar to create/maintain a .a archive library. 4. Whenever you compile, include the library in with the compile. This can be automated by modifying the c4gl script, or set up in a CFLAGS string in make. Make sure your .a is included before anything else, or it will complain. Note that this method can be fully automated using make. (That's what we're doing.) Also note that the c4gl modification method ALWAYS tries to include library functions, so you'd need to make sure that names don't conflict with non-library functions. (The shared functions should be named uniquely anyway). Any functions not needed in the library will not be linked into the executable. This is based on the .o, so if you have more than one function in a .o, then the whole .o gets linked in even if only one function in the .o is needed. The only drawback is that the .a is not dynamic, so any change still requires a re-compile to get the benefit of the change in your executable. However, this method ensures that only one version of the source is used to share among different executables. The P-code version, being only a "runner", doesn't really care if a function is defined but not used. The only way to obtain the same kind of benefit with the P-code version would be to build a program which: 1. knows the location of your source, including library source. 2. "sniffs" your source to determine what functions are being called. 3. finds those functions and "cat"s them to the .4gi, ignoring any functions which aren't needed. My guess would be that all of this is probably not worth the effort. If a function needs only a couple of functions, it would probably be easier to create a script file like: fglpc {source file list} cat those .4go's to a .4gi cat used library .4go's >> the .4gi Hope this helps/spawns a worthy discussion. Tim --- ~ SPEED 1.40 [NR] ~