Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Greg C. <chi...@mi...>]

James Michael DuPont wrote:
> 
> --- Greg Chicares <chi...@mi...> wrote:
> > [snipped other mailing lists that I don't belong to]
> >
> > James Michael DuPont wrote:
> > >
> > > libiconv is ready for scrutiny, note that the full changes to the
> > > changelog are missing, but I have to get going. So feel free to
> > > complain  that I to will leave out parts of the GPL required
> > > documenation while posting a intermediate step. This is just a work
> > in
> > > progress.
> >
> > Please help me understand the motivation for changing
> > libiconv. I thought the libiconv sources already built
> > successfully with MSYS, as well as with linux of course.
> > Have you found defects in libiconv that need correction?
> > Are you enhancing the library in some other way?
> 
> I dont want to change it, just compile all the packages needed for DIA
> under mingw32 under debian.
> 
> iconv,gettext, glib, gtk, pango, bonobo .... and others.
> 
> If you know of anyone who has ported all of these to mingw32 under
> linux, and has any downloads I will use them.
> 
> I just want to have a proper set of sources and script for easily
> compiling this stuff. The current distribution of DIA for w32 is a
> mess.
> 
> (And for libiconv as well, there are like 6-7 different distos of it!)

I share the frustration you express here and in your
'Will the real libiconv please stand up!' post sent
about five minutes before.

I'm maintaining a GPL application for win32. I support
cygwin, but use mingw by preference because the binaries
run faster. To build with mingw, developers need
  bzip2 tar make cp ls mkdir mv rm wc
  md5sum echo date patch diff sed
and for years I've been maintaining a list of win32 ports
that we've found to work, from several different sources.
If each of those fifteen tools has half a dozen subtly
different ports, that's 6^15 ways for something to go
wrong--so we 'md5sum --check' the tools in the default
makefile target.

It would probably have been much easier to use cygwin
tools exclusively. That's just not the way we evolved,
but it might have saved an awful lot of trouble finding
various native win32 ports and selecting among them.

Still, that's not ideal. 'sed' is a nasty example: its
3.02 version has some version we really wanted (forget
what exactly), but has a defect that tries to allocate
an unbounded amount of memory in certain cases. We found
various ports that all return '3.02' with '--version',
but they behave differently. Some had this defect, and
some had other defects. One was actually a 16-bit port
that ran very slowly and did nasty things if it crashed.
Some had source; others didn't. The cygwin 'sed' didn't
work for us in all cases either.

But that story has a happy ending. Version 3.02.80 does
everything we need. With MSYS (and presumably cygwin)
you just download the tarball from gnu.org and
  $ ./configure
  $ make
The lesson for me was: don't look for a port--just build
the source. I guess people in the *nix world already
knew that.

Many tools and libraries can use that approach. They
might not need any platform-specific stuff, or such
stuff might already be in place for win32. Some need a
little help--for instance, libxml2 knows about cygwin
but not mingw. We built libxml2 with mingw, but instead
of putting the dll on some webpage, we sent the patches
to the maintainer. There are too many pointless forks.

Yet with libiconv, it's my impression that
  $ ./configure
  $ make
works with MSYS, at least in the sense that it compiles;
I don't recall whether I tried 'make test'. So I wonder
whether you really need to do any work to get it to
compile with mingw. Perhaps you're using a different
shell? Not CMD.EXE I hope.