Re: [Simulavr-devel] Windows port of simulavrxx

[Bill]

Thanks. I'm aware of "cygwin.dll" issues...though I don't know about
WinAVR. I also have looked into GNUlib.

If I didn't say so, I agree with your points about being mindful of
MS-ports earlier rather than later.

I'll look into WinAVR since I don't know anything about it. I do have
preliminary ports to use CMake as the configure/build tool, but I ran
into problems autodetecting libbfd in a way that was reasonably
portable...I don't even begin to understand how to do that "right"
with CMake...so for how I'm relying solely on GNU toolsets. (perhaps
even trying to use -mno-cygwin or whatever it was on the "cygwin"
platform build...I know...problems are there too!)

Patches and suggestions always greatfully welcome! (not a jibe,
really. I do appreciate your imput)

E. Weddington wrote:

>  Bill wrote:
>
> > right...a bit off topic I suppose.
> >
> > What I had in mind for Microsoft platforms was to support the
> > "cygwin" environment. (www.cygwin.com)
> >
>  Right. That's the first step. Currently simulavr builds under
>  cygwin. (Remember, I put together WinAVR.)
>
> > I don't know if it currently builds there. I know of several
> > shortfalls, but the core simulator might be pretty close already.
> >
> >
>  I don't know if simulavrxx builds under cygwin or not. There may be
>  a high probability that it will.
>
> > If there are specific ideas we need to think about, them please
> > do share them. Unless the volume goes way up, I don't mind direct
> > email to support this.
> >
>  Ideally, it would be good to eventually have a native win32 API
>  port of simulavrxx, similar to what has happened with avrdude. The
>  main reason why this is ideal is because it is difficult to
>  redistribute binaries that are linked to the Cygwin DLL
>  (cygwin1.dll) due to DLL version conflicts (I've discussed this a
>  number of times on multiple lists.)
>
>  One of the first things to do is to identify where POSIX calls are
>  being made. A couple of options then could be: 1. Isolate the POSIX
>  calls to their own modules, then win32 modules can be built to
>  provide the same functionality. 2. I recently discovered GNUlib:
>  Savannah page: <http://savannah.gnu.org/projects/gnulib> Home page:
>  <http://www.gnu.org/software/gnulib/> GNUlib is a portability
>  library which has similarities to libiberty in GCC. (Ted, if you're
>  reading this, I would also suggest this for avarice as well.) The
>  down side is there doesn't seem to be any functionality regarding
>  sockets (which IIRC is needed for simulavr[xx] and avarice?)
>
>  Eric