This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: cooperation of cygwin and NuTCracker ??


Hi Frank,

maybe you could create a separate, small executable using
NuTCracker which does interprocess communication to a
cygwin executable via sockets or files?

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	Frank Moehle [SMTP:Frank.Moehle@Informatik.Uni-Oldenburg.DE]
> Sent:	Wednesday, October 11, 2000 11:57
> To:	cygwin@sources.redhat.com
> Subject:	cooperation of cygwin and NuTCracker ??
> 
> Hello,
> 
> We are going to use cygwin to port a set of unix programs from
> solaris to Windows NT. (Un)fortunately, we use a library from
> am external product. This Product has also been ported from solaris
> to NT, but using "NuTCracker".
> We only have access to the final .DLL of this external product
> (of cource shipped with the NuTCracker runtime enviroment).
> 
> We have already made some progress in porting the programs that do not
> need
> the external library. I really want to say that the cygwin team did a
> grat job! Everything looks and feels like unix, and we basicially only
> had to
> replace parts that were different between solaris and gnu-linux. All
> our
> Makefiled worked as expected, no need to fiddle with .exe stuff.
> (ok, there _are_ some changes, e.g. we removed chown/chgrp lines,
>  used "install" instead of "cp" to copy the compiled programs to the 
>  bin/ directory and seperated the binaries/libraries by platform 
>  by referry to $(OSTYPE))
> 
> 
> Now comes the harder part:
> 
> The DLL i was talking about is called "anaport.dll" and comed from a
> very popular
> CASE tool for embedded systems.
> 
> We have created .a library for this one, using the following lines in
> our Makefile:
> 
> ----
> API_OBJ = anaport.a
> API_DLL_NAME = anaport.dll
> API_DLL = /cygdrive/y/stmm/misc/ANAPORT/$(API_DLL_NAME)
> API_DEF = anaport.def
> 
> $(API_OBJ): $(API_DEF)
>         dlltool --def $< --dllname $(API_DLL_NAME) \
>           --output-lib $@ $(API_DLL)
>  
> $(API_DEF): $(API_DLL)
>         echo EXPORTS > $@
>         nm $< | grep ' T _stmm' | sed 's/.* T _//' >> $@
> -----
>  
> and the went on as usual:
> 
> ----
> LIBRARIES = -l<our own stuff.a> -lm
> 
> $(Our_tool):    $(Our_tool_OBJS)
>         gcc -o $(Our_tool) $(Our_tool_OBJS) $(API_OBJ) $(LIBRARIES)
> ----
> 
> 
> The first result was that we could start the resulting binary, and get
> a
> few --help lines out of it (after setting NCDIR to point to the
> nutcracker root).
> But when we tried to really use the  anaport.DLL part,
> the NuTCracker side dumped core.
> 
> 
> Are there any known issues in mixing cygwin and NuTCracker stuff ??
> Or is something important missing in the above procedure ??
> 
> 
> Thanks,
> 	Frank. 
> 
> -- 
> ======================================================================
> =
>          Frank Moehle                              | Understanding is
> a
> Work   : Uni Oldenburg,Computer Architecture Group | three-edged
> sword.
> Inhouse: frankm@haydn                              | (Vorlon saying)
> DOMAIN : Frank.Moehle@Informatik.Uni-Oldenburg.DE
> +-------------------
> ----------------------------------------------------------------------
> -
> ****            Its how you DO it, not how you don't.
> ****
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]