khan@ux1.cso.uiuc.edu (Scott Coleman) (08/20/90)
Howdy, folks. Today's hopefully-not-too-dumb question concerns linking routines in Assembly Language to a Turbo C++ program. Specifically, I want to use a Curses library (Aspen Curses) with TC++. The library compiles and links when TC++ is in "ANSI C compiler" mode, but when I attempted to link it with a C++ program, TLink couldn't find any of the symbols. My next approach was to recompile all of the LIB source files with the -P option, which forces TC++ to treat them as C++ source files. I then rebuilt the library using TLib. Now, my C++ program can find all of the symbols in the library EXCEPT those which appear in the two .ASM files. A perusal of the library contents with TLib reveals that all the C++ functions have information on the parameters stored in the library along with the symbol names (e.g. instead of just 'foo' I see 'int foo(int,char *,unsigned)'. The Assembly modules, however, lack this extra information. With them, all I can see are the symbol names. My guess is that TC++ is doing some really intense type checking, and because the symbols in the .ASM modules don't match EXACTLY with the symbols that the C++ modules in the library are looking for, TLink gets upset. How can I work around this? Ideally, I would like to insert the "extra" parameter information which is lacking for the .ASM modules. Frantic scanning of the many TC++ manuals reveals no obvious way to do this, and the section on linking TC++ with .ASM doesn't even mention the problem. If I can't insert the parameter type info, can I force TLink to relax its type checking on those .ASM modules? Is there another solution? Any assistance will be greatly appreciated. -- Scott Coleman University of Illinois khan@ux1.cso.uiuc.edu
toma@ozdaltx.UUCP (Tom Armistead) (08/25/90)
In article <1990Aug20.143139.7100@ux1.cso.uiuc.edu>, khan@ux1.cso.uiuc.edu (Scott Coleman) writes: > Today's hopefully-not-too-dumb question concerns linking routines in > Assembly Language to a Turbo C++ program. Specifically, I want to use > a Curses library (Aspen Curses) with TC++. The library compiles and links > when TC++ is in "ANSI C compiler" mode, but when I attempted to link it > with a C++ program, TLink couldn't find any of the symbols. > . . . > khan@ux1.cso.uiuc.edu The problem is that TC++ is C++ v2.x compatible, which supports 'typesafe' linking. What this means is that function names are mangled to include the type information. To fix this, use the 'extern "C"' direcive around your function prototypes. This tells the C++ compiler to NOT mangle the function names. To see an example of this, look in some the the TC++ include file (stdio.h). Ex. extern "C" int printf( char *fmt, ... ); or extern "C" { int printf( char *fmt, ... ); int strcmp( char *, char * ); } Maybe this'll do it for you? Tom -- ------------------------------- {uunet,smu,ames}!sulaco!ozdaltx!toma (Tom Armistead @ Garland, Texas) {mic,void,egsner}!ozdaltx!toma
POPOVICH@ucf1vm.cc.ucf.edu (Peter Edward Popovich) (08/28/90)
In article <1990Aug20.143139.7100@ux1.cso.uiuc.edu>, khan@ux1.cso.uiuc.edu (Scott Coleman) says: >My guess is that TC++ is doing some really intense type checking, and because >the symbols in the .ASM modules don't match EXACTLY with the symbols that >the C++ modules in the library are looking for, TLink gets upset. > >How can I work around this? Ideally, I would like to insert the "extra" >parameter information which is lacking for the .ASM modules. Frantic >scanning of the many TC++ manuals reveals no obvious way to do this, and >the section on linking TC++ with .ASM doesn't even mention the problem. >If I can't insert the parameter type info, can I force TLink to relax >its type checking on those .ASM modules? Is there another solution? Since you have TC++, I'll direct you to look at the header files. Note how they all have stuff (approxamately) like: #ifdef cplusplus struct c { #endif char *srtcpy(char *,char *); #ifdef cplusplus } #endif Please Note: This is an example only! Look at the actual header files, you'll see what actually should be there! If you enclose the function definitions in an identical struct, TC++ will expect the old style (non-OOP) object module for that function. Have Fun! Peter E. Popovich -- POPOVICH@UCF1VM.BITNET -- popovich@ucf1vm.cc.ucf.edu List Owner, TURBOC-L@UCF1VM -- #include <stddisclaim.h> -- "Who, me?"
hopper@ux.acs.umn.edu (hopper) (08/29/90)
In article <90239.223422POPOVICH@ucf1vm.cc.ucf.edu> POPOVICH@ucf1vm.cc.ucf.edu (Peter Edward Popovich) writes: > >Since you have TC++, I'll direct you to look at the header files. Note how >they all have stuff (approxamately) like: > >#ifdef cplusplus >struct c { >#endif >char *srtcpy(char *,char *); >#ifdef cplusplus >} >#endif > Thirty-five and 1/2 people have probably already said this, but it really goes like this: #ifdef _cpluplus extern "C" { #endif char *strcpy(char *, const char *); #ifdef _cplusplus } #endif The main difference is the 'extern "C" {' instead of 'struct c {'. The extern "C" construct is a standard part of the C++ 2.0 AT&T spec. It says that all prototypes in it's scope are linked as C functions, not C++ functions. You probably want to do this for any assembly routine you write because different compilers use different name mangling schemes that are generally hard to figure out for naming assembly functions. Have fun, UUCP: rutgers!umn-cs!ux.acs.umn.edu!hopper (Eric Hopper) __ /) /**********************/ / ') // * I went insane to * / / ______ ____ o // __. __ o ____. . _ * preserve my sanity * (__/ / / / <_/ / <_<__//__(_/|_/ (_<_(_) (_/_/_)_ * for later. * Internet: /> * -- Ford Prefect * hopper@ux.acs.umn.edu </ #include <disclaimer.h> /**********************/ -- -- Nils_McCarthy mtymp01@ux.acs.umn.edu rutgers!umn-cs!ux.acs.umn.edu!mtymp01 "The wonders of modern technology..." :-) :-) :-)