Follow up to New Question:

Follow up to New Question:

[Kermit Tensmeyer]

Output of Makefile:

cd ~/
make -k rrexec.exe
gcc  -o rrexec.exe rrexec.o 
C:/gnuwin32/H-i386-cygwin32/i386-cygwin32/lib/libwsock32.a
rrexec.o(.text+0x172):rrexec.c: undefined reference to `rexec'
rrexec.o(.text+0x1c1):rrexec.c: undefined reference to `recv'
gcc: Internal compiler error: program ld got fatal signal 1
make: *** [rrexec.exe] Error 1

Compilation exited abnormally with code 2 at Fri Sep 26 12:08:16

 rather than rely on the -l form I added the explict load of the
 library.

 in library libwsock32.a I extracted the symbols, and found this

ds62.o:
00000000 b .bss
00000000 d .data
00000000 ? .idata$4
00000000 ? .idata$5
00000000 ? .idata$6
00000000 ? .idata$7
00000000 t .text
00000000 ? ___imp_rexec@24
         U __head_libwsock32_a
00000000 T _rexec@24

   from this I conclude that somehow the function call 'rexec' 
 does _not_ get statisfied to the ident _rexec@24_.

 so how is gnuwin32 differenet from the orthodox Gnu C compiler?

  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..
-- 
-------
  Kermit Tensmeyer    (E & T - Networking)
  Kermit@ticnet.com     Dallas
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Follow up to New Question:

[Alex]

On Fri, 26 Sep 1997, Kermit Tensmeyer wrote:

> Output of Makefile:
> 
> cd ~/
> make -k rrexec.exe
> gcc  -o rrexec.exe rrexec.o 
> C:/gnuwin32/H-i386-cygwin32/i386-cygwin32/lib/libwsock32.a
> rrexec.o(.text+0x172):rrexec.c: undefined reference to `rexec'
> rrexec.o(.text+0x1c1):rrexec.c: undefined reference to `recv'
> gcc: Internal compiler error: program ld got fatal signal 1
> make: *** [rrexec.exe] Error 1
> 
> Compilation exited abnormally with code 2 at Fri Sep 26 12:08:16

>    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.
 
>  so how is gnuwin32 differenet from the orthodox Gnu C compiler?

It doesn't have a libc in the usual sense.
 
>   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.  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.

- alex

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Follow up to New Question:

[Kermit Tensmeyer]

> 
> On Fri, 26 Sep 1997, Kermit Tensmeyer wrote:
> 
> > Output of Makefile:

 <deleted for space...>


> >    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".

Re: Follow up to New Question:

[Alex]

On Sat, 27 Sep 1997, Kermit Tensmeyer wrote:

> > 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?

It was probably not exported correctly, or just junk in the first place.
 
>   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?

My understanding is that most (if not all) windows programs are linked
against a C runtime dll (usually crtdll.dll).   GNU-Win32 uses its own
dll to provide a Unix like enviroment (cygwin.dll) which provides
wrappers and missing functions.  So, you _could_ call it a libc, I don't.
By b19, it might not be linked to cygwin.dll by default, that's still up
in the air I _think_.

>   If it does not support the basic GNU requirments why not? How or
> why was it broken?

>  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.

Ok, then it is probably in the NT version of wsock32.dll.

>   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.

I don't know.  I haven't looked at the source in a while.  However if the
functions are indeed in wsock32.dll, you can create an export list and
then a .a style library to use rexec from (that's how libwsock32.a and
libcygwin.a were created). Instructions are on a
link on cygnus's web page.  I can find them if you would like them.

>   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]

The should be.
 
>   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 have no idea.

- alex

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Follow up to New Question:

[Alex]

I apologize for the lengthy post.  I accidentally hit reply to all
recipients.

- alex

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".