Path: utzoo!attcan!uunet!lll-winken!tekbspa!optilink!cramer
From: cramer@optilink.UUCP (Clayton Cramer)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Replacing a Microsoft C library routine
Keywords: C, Microsoft, link
Message-ID: <786@optilink.UUCP>
Date: 9 Jan 89 18:08:46 GMT
References: <5041@b-tech.ann-arbor.mi.us. <2521@stiatl.UUCP.
Organization: Optilink Corporation, Petaluma, CA
Lines: 34

In article <2521@stiatl.UUCP., john@stiatl.UUCP (John DeArmond) writes:
. In article <5041@b-tech.ann-arbor.mi.us. zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
. .For a few programs I've written, I believe that I need to disable 
. .calls to chkstk (I'm calling microsoft C routines from an interrupt 
. .handler).  I know about the /Gs option, but I'm concerned that the 
. .library routines might also call it.  
. .
. .The best solution seems to be to write a null chkstk routine and link 
. .it in.  This creates an error message about multiply defined symbols.  
. .Is there any way to get the linker to quietly use the first chkstk 
. .routine it finds?  
. .
. 
. Use the /NOE linker switch.  The multiply defined error message the 
. linker generates tells you to use this switch.  
. 
. RTFM .. er ... RTFcrt   :-)

Nope.  /NOE isn't enough.

. 
. .I've tried removing chkstk from the library with -chkstk, but this seems
. .to remove some other needed routine or variable (STKHQQ).

. .  Jon Zeeff			zeeff@b-tech.ann-arbor.mi.us

Because STKHQQ is defined in the real chkstk function, the null one needs
to define STKHQQ also, or to resolve STKHQQ (even with /NOE), the real
chkstk function will be linked as well, causing multiply-defined
errors.
-- 
Clayton E. Cramer
{pyramid,pixar,tekbspa}!optilink!cramer
Disclaimer?  You must be kidding!  No company would hold opinions like mine!