Re: Mixing 4GL with Curses Screen Handling

>From: Jim Welch <mbsoft@ix.netcom.com> >Date: Thu, 23 Jan 1997 22:52:46 -0500 >X-Informix-List-Id: <news.32940> > >I'm working on making some modifications to an existing GUI written >entirely in 'C' with curses screen handling. My mods include adding >several new 4GL forms and modules to the existing application. Rather >than rewriting existing portions of the GUI, I plan to combine 4GL >screen handling with the curses handling. Now my problem... > >When I am building the new app, I seem to come across a problem with the >linker and duplicate references to some curses library functions. I >wrote a small test program that highlights the problem: > >[...code omitted...] > >Building from the Makefile above yields the following errors in Ultrix >4.4: >/usr/informix/lib/libnforms.a(curses.o):_endwin:multiply defined >/usr/informix/lib/libnforms.a(tputs.o):tputs:multiply defined >/usr/informix/lib/libnforms.a(attrset.o):wattrset:multiply defined > >Now, if I modify the Makefile above and omit the cursesX library, the >test program will compile without errors. However, if I add some >additional cursesX calls such as 'mvwprintw', 'beep' etc. to the test >program, these will will not be found during the link. > >Has anyone else experienced this or similar problems. This is one of those not-so-frequently asked questions which appears every couple of years or so. Yes, what you are finding are absolutely standard problems. Although I4GL uses termcap (and curses) internally, it uses its own home-brew version based on an archaic (read 10+ years old) release of the curses library, trimmed down to only include the functions which I4GL itself uses, and hacked up to provide some extra functionality (such as optional terminfo support, and some colour support, etc). This leads to a number of problems. (1) You probably don't have a header which declares the key structures in the correct form. There are no guarantees that the I4GL curses stuctures match your systems curses structures. However, you should be able to get away with declaring: typedef struct Window WINDOW; Since the code only ever gets 'WINDOW *' items, this is sufficient to allow you to get on with the curses library. (2) If you try to use a non-I4GL function, you will haul in the wrong code from the system library. And since the I4GL curses functions are not necessarily packaged the same way as the system curses functions, you find that you have doubly defined functions. If you can find the curses function in I4GL, then you can use it with a fair degree of confidence that you'll get the correct behaviour. If the curses 'function' is normally a macro, then you've got a problem -- the macro expansion isn't available. If it isn't in I4GL curses, you can't use it with I4GL. I attach some old (1990-2 vintage) email which discusses I4GL and curses. Towards the end is a list of functions present and not present in the I4GL curses library. Bear in mind that this is 6+ years old and the list of functions may have changed slightly, but it will be a pretty good guide. Note that ESQL/C does not run into the same problems; the set of ESQL/C functions should be disjoint from the set of system curses functions. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> =========================================================================== Date: Fri, 3 Aug 90 16:26:57 PDT From: elliotd@cougar (Elliot Danziger) Subject: Re: Curses Library Support >Date: Fri, 3 Aug 90 15:24:13 BST >From: stevepo@obelix (Steve Pope) > >I've just been hit with a problem that I'm struggling to resolve and >would appreciate any advice that anybody has to offer. > >We have a developer in the UK running two teams one developing in >ESQL/C and the otherdeveloping front-ends in Prolog and C. Both are >making use of curses libraries, but are hitting problems when they >try to link (double defines etc). > >They seem to feel that we are non-standard in the way that we tackle >curses. Of that there is no doubt! :-) >Not being a C programmer (long live 4GLs), I don't understand the >implications of this, or how we can suggest a workaround. > >Has anybody come across this type of scenario / got any suitable >suggestions. I'm coming to this subject a little late but i'll throw in my $.02 anyway for what it's worth... As already mentioned by Mark, Mike, Dave, and J.D. there should *not* be multiply defined symbols when linking ESQL/C with standard curses as the ESQL script does not link in libforms.a. If for some reason libforms.a is still causing conflicts (if as suggested they are using the c4gl script - and for some reason *need* to do this) they might as a last resort want to try the following workaround: 1. Compile a list of the multiply defined definitions and which files they first appear in (that should be part on the linker's error messages). 2. Use 'ar' to extract the individual .o modules from both libform.a and the curses library (usually libcurses.a and/or libtermcap.a). 3. Explicitly link the needed .o modules from one extracted library or the other making sure to avoid redundant definitions. An alternative and possibly simpler method for steps 2 and 3 would be to simple use 'ar' to *remove* the redundant definition from one of the 2 libraries (make sure you have a backup, of course). All this might and might not work depending upon what your application is doing. For example there might be many functions contained within a single .o module that you want to remove - some of which are causing multiple definitions - but others which are *needed* and are not to be found elsewhere (in the interests of not getting carried away with an idea, we will not suggest changing the function names in the symbol table :-) ). You will also need a pretty decent low-level knowledge of curses (standard and informix version) to decide who's version to use to resolve a particular link request (e.g. I would use the Informix version for basic functions like initscr() and endwin() because of additional setup parameters needed by other informix curses functions). All in all, not a pleasant workaround but then again this is a last resort suggestion... =========================================================================== From: davek@newjersey (David Kosenko) Subject: Re: Curses, how do you link it in? Date: Mon, 13 Jul 92 11:09:44 GMT > My customer wishes to link his editor in with his 4GL application. His editor > is written using curses functions, therein lies the problem. I'm sure you all > know that linking curses with 4GL is a bitch to say the least. What I'm > looking for is someone who has successfully done this and knows either ... > > a) What curses functions we define in our code ? > > b) What curses functions need extracting from the Unix libcurses.a ? > > c) If nothing else, just plain how the hell do you do it without > tearing your hair out and spending endless hours doing "ar x ..."s ? > >