problem of compiler using libc, urgent

Hi,
We meet a very strange issue when developing using libc.
We are building a socket client application on Netware, and use watcom as
compiler tool.
At first, we use clib and libc together, and add a line
"@C:\novell\ndk\nwsdkc\libc\imports\libc.imp" to ALL.IMP, by this way,
the
code can be compiled successfully, but when we load the nlm file on
Netware, there is nothing shown on console, but in our code, we add many
printf and consoleprint for debugging.
we think this is caused by the compatibility between clib and libc, so we
remove all items related to clib(the reasion we keep libc is libc provides
socket API), but when we compile the code, it reports an error: 
loading object files
Error! E2028: __CHK is an undefined reference

Hi,
yushuang@cn.ibm.com wrote in news:yB5bi.542$%54.209@prv-
forum2.provo.novell.com:

> Hi,
> We meet a very strange issue when developing using libc.
> We are building a socket client application on Netware, and use watcom as
> compiler tool.
> At first, we use clib and libc together, and add a line
> "@C:\novell\ndk\nwsdkc\libc\imports\libc.imp" to ALL.IMP, by this
way, 
the
> code can be compiled successfully, but when we load the nlm file on
> Netware, there is nothing shown on console, but in our code, we add many
> printf and consoleprint for debugging.
I guess that your NLM closes its screen directly after execution - just add 
a pressanykey() as very last call before you exit, and the screen keeps 
open...
the behavior of libc is here other than what you know from clib.

> we think this is caused by the compatibility between clib and libc, so we
> remove all items related to clib(the reasion we keep libc is libc 
provides
> socket API), but when we compile the code, it reports an error: 
> loading object files
> Error! E2028: __CHK is an undefined reference
> Can anybody give us some help about this issue? Thank you very much.
you should not mix up clib and libc;
its often valid to call libc functions from an NLM copiled as clib, but not 
the other way - its generally not supported to call a clib function from a 
libc NLM, although in some cases this might work if the clib function needs 
no context.
In addition clib does support socket connectivity, but the SDK for that is 
not bundled as with libc, but instead you have to download separately - I 
think its named 'Server Protocol Library', and implements a bsdsocket 
interface.

HTH, Günter.

Guenter wrote:
> Hi,
> yushuang@cn.ibm.com wrote in news:yB5bi.542$%54.209@prv-
> forum2.provo.novell.com:
> 
>> Hi,
>> We meet a very strange issue when developing using libc.
>> We are building a socket client application on Netware, and use watcom
as
>> compiler tool.
>> At first, we use clib and libc together, and add a line
>> "@C:\novell\ndk\nwsdkc\libc\imports\libc.imp" to ALL.IMP, by
this way, 
> the
>> code can be compiled successfully, but when we load the nlm file on
>> Netware, there is nothing shown on console, but in our code, we add
many
>> printf and consoleprint for debugging.
> I guess that your NLM closes its screen directly after execution - just add

> a pressanykey() as very last call before you exit, and the screen keeps 
> open...
> the behavior of libc is here other than what you know from clib.
Without making a special call, the NLM's screen in a CLib NLM will not 
close automatically: you have to press a key. LibC's is just the 
opposite: it will not remain active unless you do make one of two 
possible calls.
> 
>> we think this is caused by the compatibility between clib and libc, so
we
>> remove all items related to clib(the reasion we keep libc is libc 
> provides
>> socket API), but when we compile the code, it reports an error: 
>> loading object files
>> Error! E2028: __CHK is an undefined reference
It is a stack-overflow aid built into Watcom and depends on a compiler 
switch. The symbol comes from CLib. LibC was not primarily a Watcom 
direction, so it didn't get this same treatment.
>> Can anybody give us some help about this issue? Thank you very much.
> you should not mix up clib and libc;
> its often valid to call libc functions from an NLM copiled as clib, but not

> the other way - its generally not supported to call a clib function from a

> libc NLM, although in some cases this might work if the clib function needs

> no context.
Günter is right: only disaster awaits you if you compile with both LibC 
and CLib headers or link with both sets of import files.
> In addition clib does support socket connectivity, but the SDK for that is

> not bundled as with libc, but instead you have to download separately - I 
> think its named 'Server Protocol Library', and implements a bsdsocket 
> interface.
The BSD socket library is available from CLib without additional 
download for basic functionality. BSD socket connectivity in CLib is one 
of the oldest features of that product. WinSock is a little more 
confusing to use and it requires an additional download and tricky (but 
not impossible) headers.