From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kermit Tensmeyer" To: Alex Cc: gnu-win32@cygnus.com Subject: Re: Follow up to New Question: Date: Sat, 27 Sep 1997 13:20:00 -0000 Message-id: <199709272020.NAA02980@cygnus.com> References: <342BF5C1.549F28B7@ticnet.com> X-SW-Source: 1997-09/msg00683.html > > On Fri, 26 Sep 1997, Kermit Tensmeyer wrote: > > > Output of Makefile: > > from this I conclude that somehow the function call 'rexec' > > does _not_ get statisfied to the ident _rexec@24_. > > Right, because it's not supported. It's probably not supposed to be in > there. In this particular sense, what does "it's not supported" mean? rexec is a supplied executible in the NT OS. (rexecD is not supported except in the MS NT Supplement Disk.) Rexec, RSH are RFC based protocols that communicate with a server The include files include a define for the Protocol. I expect that the function is supported but not the server. > > > so how is gnuwin32 differenet from the orthodox Gnu C compiler? > > It doesn't have a libc in the usual sense. You mean it does not? have any default library, that gets auto loaded into the compile? It does not have a standard library to handle unix standard function calls? If it does not support the basic GNU requirments why not? How or why was it broken? > > > oh yes, the code was copied from the GNU C for Unix and linked > > without explict libraries. > > > > Under GNU C, rexec and recv are included in the libc.a.. > > rexec and recv are both socket functions. > recv is STREAM_SOCK operation in that it reads bytes from a IO Stream. The prior operation connected the output of a socket to an IO stream. Rexec is a function SOCKET *rexec(char **host, int port, char *UserID, char *PassWD, char *cmd, FileIOSTream *ErrOutFile); which use port 512 to communicate to remote site host. the remote service expects zero terminated ascii port number of ErrOut Service UserID\0 PassWrd\0 Command\0 Socket is used for bi-directional IO stdin/stdout I _think_ that recv might be a > function in wsock32.dll (try running nm or strings on it and/or > winsock.dll). I _think_ the functions that need wrappers and that aren't > in the Win32 api are included in the "libc" a.k.a. libcygwin.a/cygwin.dll. > I _think_ all the functions that are copied straight over from Win32 dlls > have their own .a libs. > in either event the calls are not being found in the load. so why doesn't the functions 'rexec' or 'recv' find the functions in either the explict load or the default libcygwin.a. Is there an option in this version of the compiler to show the assembly version of the code? [ Unix, VMS versions of GCC use -s] What I want to know is how to map names from the C version of the file to the library version of the file. I assume that x = fibn(5, 12) in C or CC generates a request for a function _fibn@8 (two parametes on stack) and it would look for that function in a library. alternativly: an include file might translate a function xxxx to a function like cygnus_xxxx and then a library would supply the cygnus_xxxx function which would act in the place of the original xxxx function. Kermit Tensmeyer kermit@ticnet.com - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request@cygnus.com" with one line of text: "help".