Re: Win32 Zinf with MingW

"David Hough" <[email protected]> writes:

> Hi,
>
> I been playing around recently with trying to compile the current
> version  of Zinf using MingW and GTK+ on Windows. This is based on the
> work I did  last year ([email protected]/zinf--mingw--0.1)
> along the same  lines, except this time I've been modifying the
> existing Autoconf/Automake  build files.
>
> I've now got as far as a usable patch that can build the normal  GTK+
> player and musicbrowser UI's, with support for WAV/MP3 files.
>
> I've also written up some basic instructions on how to set-up a MingW
> development environment for Zinf using MSys:
> http://www-users.york.ac.uk/~djh123/mingw.txt
>
> The Patch:
> http://www-users.york.ac.uk/~djh123/zinf-mingw.diff
>
>
> There are still serious issues with it at the moment that need
> cleaning up  (it breaks the Linux build, etc.) so this is still very
> much a work in  progress.
>
> Note: To run from the build directory, make sure that "." is in your
> path  and execute ./zinf instead of ./base/zinf
>
>
> Apart from various bits of tweaking, converting int32 to int32_t,
> etc.,  there are two major changes I've had to make to get it too
> work. The most  significant and far reaching of these is the
> separating of the Zinf base  executable into zinf.exe and libzinf.dll
>
> This is because Windows doesn't allow shared libraries (ie the
> plugins)  that have undefined symbols in them. Currently we compile
> the plugins, and  don't link them to anything until they are loaded at
> runtime, when they're  linked to the already running Zinf executable
> (at least, I think that's  how it works). This isn't allowed on
> Windows, and neither is linking  against an executable, so we have to
> create a library with all the base  classes in them so that the
> plugins can link to it, hence libzinf.
>
I agree that this is unfortunate, and Windows is maybe not the only
platform that has this weaknesses, I think some older Unices do, also.

> This leads to another significant problem when compiling, libzinf
> depends  on the base I/O classes in the folder io/src. However, all
> the I/O plugins  also in the subdirectory io, depend on libzinf. So a
> make will build the  base I/O classes, and then fail attempting to
> build the I/O plugins. To  make successfully we actually have to
> execute
>
> make; cd base; make; cd ..; make
>
> I'm not really sure there's a good solution to this, without
> re-organising  the source tree.
>
Which is kind of a no-no with CVS; how about dumping CVS and switching
to Arch completly?

> Obviously the patch still needs a lot of work, but I would appreciate
> any  feedback anyone might have. Please feel free to try this out, as
> it would  be great if we could restore Windows support to Zinf.
>
I think this is very much appreciate work by the current users of
Windows Zinf versions and also will enhance overall portability of
Zinf.

[ Disclaimer: I'm not really a Zinf developer, I only did rewrite to
  build system to use automake and maintain the Debian packages ]

Cheers, Rotty
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | [email protected]
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

It's *GNU*/Linux dammit!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click