setup changes to build standalone

[Earnie Boyd]

Charles Wilson wrote:
> 
> Robert Collins wrote:
> 
> > Yes. I even documented all this some time back on
> > http://www.cygwin.com/ml/cygwin-apps/2001-11/msg00634.html, but
> > predicatably enough, no patches where forthcoming. Probably due to the
> > complete lack of a prebuilt bz2lib for mingw (that my cursory searches
> > have looked for).
> 
> https://sourceforge.net/projects/mingwrep/
> 

I don't know if the maintainers of this site are still maintaining it. 
Paul Sokolovsky isn't active any longer and Stefan Jahn isn't a MinGW
developer.  This is one of those projects that I wish weren't.  OTOH,
https//sourceforge.net/projects/mingw/ would be willing to upload any
MinGW package if it followed the --prefix=/mingw --host=mingw32
packaging rules (which unfortunately aren't documented except in the
mingw-dvlpr archives) and that person was willing to maintain the
pacakge (would need a SF account and be listed as a MinGW developer).

> 
> >>I wonder if we need a "mingw-libs" package.
> >>
> >
> > Yes, please, please, yes. I would really really love it if some of the
> > common libs (zlib, bz2lib, stdc++) where available in a setup.exe
> > installable pacakge.
> 
> Yes, I like this too -- but I'm nervous about it growing ridiculously
> large.  What if (eventually) setup.ini turns into XML?  Do we put a
> mingw build of libxml into 'mingw-libs'?  How far does this go?
> (visions of full{mingw}.exe)
> 
> OTOH, we've already discussed (and discarded, thank g-d) the idea of
> (for instance) the zlib maintainer providing both a
> cygwin-setup-installable zlib package (/usr/bin/cygz.dll,
> /usr/lib/libz.[dll|a]) and a cygwin-setup-installable mingw-zlib package
> (/usr/bin/mgwz.dll, /usr/lib/mingw/libz.[dll|a]).  Ditto bzip2, libxml,
> ...  we are not a mingw-porting factory.
> 

This is good.  IMO, there should be no binaries not dependent on
cygwin1.dll in the /bin a.k.a. /usr/bin and that the /bin and /usr/bin
directories be marked as --cygwin-executable.  One reason for doing this
is that it speeds the execution process for spawning by avoiding win32
translations.

> >>2) The above won't work in a cross build environment.  You could say
> >>   CC='i686-pc-cygwin-gcc -mno-cygwin'..., I guess.
> > for cross compiles:
> > ../setup/configure --host=i686-pc-mingw32 --build-i686-pc-linux
> > should do it (assuming a mingw32 cross compiler is present), or a
> > combination using the CC string you have above with the mingw host will
> > work too.
> 
> whatever happened to the idea of an official cygwin package, that
> contained a true cygwin-host, mingw-target cross compiler?  Didn't
> somebody or other volunteer to provide that?
> 

Oh, I thought about it sometime ago, I've been busy with MSYS and have
decided against my maintaining another package.  Perhaps when Danny gets
3.1 up he can provide a Cygwin hosted Mingw32 targeted set of binaries. 
I also remember a discussion on one of Cygwin's lists about using
scripts and symlinks to emulate this and may be the smartest way to go
about providing cross build emulation.

> (Granted, we still need 'cygwin-gcc -mno-cygwin' for the "self-hosting"
> feature of cygwin1.dll, but there's no real need to *require* cygwin-gcc
> -mno-cygwin for setup.exe, now that setup has been moved out of the
> winsup tree)
> 

Well, if you had a mingw32-gcc (cygwin hosted, mingw32 targeted) then
you could use that instead of `gcc -mno-cygwin'.

> >>anything that is non-simple.  I haven't looked at it in a
> >>while, though, so maybe things have changed.
> >>
> >
> > It really depends on what you want to do. Some stuff it does
> > spectalularly well, some things it has trouble with. With the 'cross
> > compiling but not' approach, it would almost certainly have some trouble
> > :}.
> 
> see above, true cross compiler...
> 

Or even the simulated with script and symlink one.

Earnie.