RFD: cygwin + *native* MinGW compiler

RFD: cygwin + *native* MinGW compiler

[Charles Wilson]

Pursuant to a discussion on the libtool list, I'm trying to get a feel
for how many cygwin users rely on the cygwin environment to drive the
*native* MinGW gcc compiler.  That is, incantations like this:

1a)
cygwin$ some-src-pkg/configure \
  --build=i686-pc-cygwin --host=mingw32 \
  CC=/c/MinGW/bin/gcc.exe \
  CXX=/c/MinGW/bin/g++.exe \
  NM=/c/MinGW/bin/nm.exe \
  DLLTOOL=/c/MinGW/bin/dlltool.exe \
  OBJDUMP=/c/MinGW/bin/objdump.exe \
  LD=/c/MinGW/bin/ld.exe

or possibly

1b)
cygwin$ export PATH=/c/MinGW/bin:$PATH
cygwin$ some-src-pkg/configure \
  --build=i686-pc-cygwin --host=mingw32

Note that this is *DIFFERENT* than installing a true cygwin-hosted
mingw-target cross-compiler, and just doing

2)
cygwin$ some-src-pkg/configure \
  --build=i686-pc-cygwin --host=i686-pc-mingw32

It is ALSO different than the (deprecated, unsupported,
go-away-don't-bother-us) incantation:

3)
cygwin$ some-src-pkg/configure \
  --build=i686-pc-cygwin --host=i686-pc-mingw32 \
  CFLAGS='-mno-cygwin'

I hope this is considered on-topic here, because I'm interested in the
uses of the cygwin environment itself.  I don't want reports of why it
doesn't work, or how hard it is to get one of the incantations above to
work.  I just want to get an idea of how many people are currently,
actually, successfully, doing something like 1a) or 1b) above.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Christopher Faylor]

On Tue, Jan 27, 2009 at 09:21:59PM -0500, Charles Wilson wrote:
>I hope this is considered on-topic here, because I'm interested in the
>uses of the cygwin environment itself.

It's certainly on-topic.  I'd be interested in the responses too.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Warren Young]

Charles Wilson wrote:
> Pursuant to a discussion on the libtool list, I'm trying to get a feel
> for how many cygwin users rely on the cygwin environment to drive the
> *native* MinGW gcc compiler.

I do half of what you're asking: use Cygwin's bash shell as an 
environment to drive mingw32-make on MinGW-specific Makefiles.  I posted 
here how I manage the PATH issues and such that you touch on:

	http://www.cygwin.com/ml/cygwin/2008-05/msg00092.html

I do this only for MySQL++, a library I maintain, which targets MinGW 
among many other platforms.  I use the MinGW sub-environment described 
above only as long as I need to do some test or fix for MinGW, then pop 
back out into a normal Cygwin environment.

MySQL++ uses Bakefile to build the MinGW makefile, however, so I don't 
know how relevant my experience is to you.  Bakefile more or less 
replaces libtool and automake, allowing easier porting to non-POSIX 
platforms.  Thus, my use of Cygwin to drive the MinGW toolchain is 
limited to using bash as an alternative to the MinGW Prompt you get on 
installing MinGW.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Greg Chicares]

On 2009-01-28 02:21Z, Charles Wilson wrote:
> Pursuant to a discussion on the libtool list, I'm trying to get a feel
> for how many cygwin users rely on the cygwin environment to drive the
> *native* MinGW gcc compiler.

I use the native MinGW compiler in a Cygwin environment,
successfully, many hours every day.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Charles Wilson]

Greg Chicares wrote:
> On 2009-01-28 02:21Z, Charles Wilson wrote:
>> Pursuant to a discussion on the libtool list, I'm trying to get a feel
>> for how many cygwin users rely on the cygwin environment to drive the
>> *native* MinGW gcc compiler.
> 
> I use the native MinGW compiler in a Cygwin environment,
> successfully, many hours every day.

A few additional questions, then:

Do you use gnu-style configured projects (autoconf, automake, libtool,
all that?) -- or some other build framework?

Do you use cygwin's make (which version?), mingw32-make, or perhaps a
cygwin build of msys's csmake/cpmake?

Do you use gcc's -M* options for generating dependencies -- with
mingw-gcc, these rules will be in dos format and cygwin-make-3.81
doesn't grok them?

What about creating static libraries? If you use mingw's ar.exe, do you
use explicit `cygpath` rules to convert unix paths to the DOS paths that
version of ar can understand, or some other technique?

For a hint about why I started this thread, and why I am asking these
questions, see
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00163.html
-- especially my failures with

$ export PATH="/c/MinGW/bin:$PATH"
$ ../libtool/configure --build=i686-pc-cygwin --host=mingw32

This led to a suggestion that "--build=cygwin --host=mingw32" should
always be interpreted as: mingw32-gcc is a cygwin-hosted cross compiler,
NOT the native MinGW-project supported gcc (and if it IS the native
MinGW one, expect breakage). I'm not sure such a sweeping statement is
accurate, or wise -- will that assumption break people's exising
(working) setups?

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Yaakov (Cygwin/X)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Charles Wilson wrote:
> This led to a suggestion that "--build=cygwin --host=mingw32" should
> always be interpreted as: mingw32-gcc is a cygwin-hosted cross compiler,
> NOT the native MinGW-project supported gcc (and if it IS the native
> MinGW one, expect breakage). I'm not sure such a sweeping statement is
> accurate, or wise -- will that assumption break people's exising
> (working) setups?

If you're talking about configure gcc with those flags, then wouldn't
that usually mean that you're cross-compiling a regular, native MinGW
compiler?  If you want a cygwin-hosted MinGW cross-compiler, you should
be using "--build=cygwin --host=cygwin --target=mingw32".  I would be
hesitant to change the usual meaning of build/host just for
Cygwin/MinGW; I don't think we need to add to the confusion that most
people have about Cygwin.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkl/99AACgkQpiWmPGlmQSPwWwCg2zTu9HT+7n9KllpstMDFMQSI
54kAoMO87bM+BuTptalxE3hHkP8uOYoU
=7GVr
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Charles Wilson]

Yaakov (Cygwin/X) wrote:
> Charles Wilson wrote:
>> This led to a suggestion that "--build=cygwin --host=mingw32" should
>> always be interpreted as: mingw32-gcc is a cygwin-hosted cross compiler,
>> NOT the native MinGW-project supported gcc (and if it IS the native
>> MinGW one, expect breakage). I'm not sure such a sweeping statement is
>> accurate, or wise -- will that assumption break people's exising
>> (working) setups?
> 
> If you're talking about configure gcc with those flags,

No, I'm talking about configuring/compiling *other* stuff, using some
gcc that is found via the normal rules (prefixing a triple to 'gcc' when
specified by build/host/target options, looking in PATH, etc).

> then wouldn't
> that usually mean that you're cross-compiling a regular, native MinGW
> compiler?  If you want a cygwin-hosted MinGW cross-compiler, you should
> be using "--build=cygwin --host=cygwin --target=mingw32". 

Right, if I'm building a compiler.  I'm not -- although that wasn't very
clear, since the only examply I gave was Danny's incantation for
building gcc, a compiler.  Oops.

I'm talking about building, say, ncurses so that it will run "natively"
(that is, in the mingw environment without cygwin).  The question is,
what assumptions should be made about the compiler that is used to
compile ncurses, when you configure ncurses using --build= --target=?
Does that compiler  understand /cygdrive/c/foo, or C:\foo?

Only compilers and linkers have --targets.  Everything else, you
(cross)compile using build/host (or just host; build is implicit). So,
the implication of the suggestion above is that:

../ncurses/configure --build=cygwin --host=mingw32

would mean that the gcc involved runs on the cygwin build platform, and
understands /cygdrive/c/foo, but the ncurses library and tools will be
native mingw32 and will only understand C:\foo. That is, it is a
cygwin->mingw cross compiler. (Bringing this down to earth:
specifically, when libtool is creating a wrapper executable -- say, for
tic.exe -- using the cross-compiler, the wrapper exe will be a native
win32 prog, and will need the DOS path to the exe it needs to "wrap".
Not the cygwin path -- and libtool should use cygpath to obtain that DOS
path).

OTOH,

../ncurses/configure --build=mingw32 --host=mingw32

would mean that the compiler TOO only understands C:\foo. That is, it is
a native MinGW compiler as distributed by the MinGW team.  (Back to
earth: specifically, when libtool is creating a wrapper executable using
this "native" compiler, the wrapper exe will be a native win32 prog, and
will need the DOS path to the exe it needs to "wrap". However, because
of the oddities of "MinGW" $build -- it's actually msys, and has its own
idea of a unix-like path -- libtool will need to convert that unix-like
path to DOS format using the msys mechanism to do so. NOT cygpath).

These are both logical scenarios, and represent the "normal" way of
interpreting build/host for an cross-compile or native setup [other than
the utter weirdness that is msys].  However...and here's the rub...until
now the various win32 "hosted" platforms have been rather lax about
these distinctions.  So, for instance, Danny can currently get away with
the following:

cygwin-machine$ ../gcc/configure --build=mingw32 --host=ming32
--target=mingw32

even though $build is NOT, actually, mingw32 (or even msys). It's
cygwin. Enforcing the "normal" interpretation will break that usage
(Back to earth: because the "wrong" mechanism (msys->mingw, instead of
the true cygwin->mingw) to convert unix-like paths to the DOS path
needed by the wrapper exe will be used. Don't lie to your tools about
their $build environment...)

Maybe this usage *should* be broken (or strongly discouraged, with an
esoteric workaround for those who insist on mistreating their tools). I
dunno.

Seems kinda harsh, to break something that currently works (even if it
is evil) -- and the point of this thread, really, is to see how many
people use cygwin + mingw in situations where they may be tempted to --
or already do -- lie to their configure scripts about $build.

> I would be
> hesitant to change the usual meaning of build/host just for
> Cygwin/MinGW; I don't think we need to add to the confusion that most
> people have about Cygwin.

I don't think anyone is proposing that; I think the original suggestion
actually enforces a more "normal" (e.g. like *nix/bsd/sol/etc)
interpretation on the build/host/target triples. No more pretending that
build=mingw32 when it's really cygwin; etc.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Yaakov (Cygwin/X)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Charles Wilson wrote:
> Right, if I'm building a compiler.  I'm not -- although that wasn't very
> clear, since the only examply I gave was Danny's incantation for
> building gcc, a compiler.  Oops.
> 
> I'm talking about building, say, ncurses so that it will run "natively"
> (that is, in the mingw environment without cygwin).  The question is,
> what assumptions should be made about the compiler that is used to
> compile ncurses, when you configure ncurses using --build= --target=?
> Does that compiler  understand /cygdrive/c/foo, or C:\foo?

That's a totally different story.  I think that would be obvious;
- --build=cygwin --target=mingw32 should mean you're using a Cygwin-based
MinGW cross-compiler.  AFAIK that's consistent with other platform
combinations.

> Only compilers and linkers have --targets.  Everything else, you
> (cross)compile using build/host (or just host; build is implicit). So,
> the implication of the suggestion above is that:
> 
> ../ncurses/configure --build=cygwin --host=mingw32
> 
> would mean that the gcc involved runs on the cygwin build platform, and
> understands /cygdrive/c/foo, but the ncurses library and tools will be
> native mingw32 and will only understand C:\foo. That is, it is a
> cygwin->mingw cross compiler. (Bringing this down to earth:
> specifically, when libtool is creating a wrapper executable -- say, for
> tic.exe -- using the cross-compiler, the wrapper exe will be a native
> win32 prog, and will need the DOS path to the exe it needs to "wrap".
> Not the cygwin path -- and libtool should use cygpath to obtain that DOS
> path).

Right.

> OTOH,
> 
> ../ncurses/configure --build=mingw32 --host=mingw32
> 
> would mean that the compiler TOO only understands C:\foo. That is, it is
> a native MinGW compiler as distributed by the MinGW team.  (Back to
> earth: specifically, when libtool is creating a wrapper executable using
> this "native" compiler, the wrapper exe will be a native win32 prog, and
> will need the DOS path to the exe it needs to "wrap". However, because
> of the oddities of "MinGW" $build -- it's actually msys, and has its own
> idea of a unix-like path -- libtool will need to convert that unix-like
> path to DOS format using the msys mechanism to do so. NOT cygpath).

So far so good.

> These are both logical scenarios, and represent the "normal" way of
> interpreting build/host for an cross-compile or native setup [other than
> the utter weirdness that is msys].  However...and here's the rub...until
> now the various win32 "hosted" platforms have been rather lax about
> these distinctions.  So, for instance, Danny can currently get away with
> the following:
> 
> cygwin-machine$ ../gcc/configure --build=mingw32 --host=ming32
> --target=mingw32
> 
> even though $build is NOT, actually, mingw32 (or even msys). It's
> cygwin. Enforcing the "normal" interpretation will break that usage
> (Back to earth: because the "wrong" mechanism (msys->mingw, instead of
> the true cygwin->mingw) to convert unix-like paths to the DOS path
> needed by the wrapper exe will be used. Don't lie to your tools about
> their $build environment...)
>
> Maybe this usage *should* be broken (or strongly discouraged, with an
> esoteric workaround for those who insist on mistreating their tools). I
> dunno.

Of course it's broken, period.  And just like all the other
misconceptions around Cygwin, I don't see why it we shouldn't be allowed
to fix it.

> Seems kinda harsh, to break something that currently works (even if it
> is evil) -- and the point of this thread, really, is to see how many
> people use cygwin + mingw in situations where they may be tempted to --
> or already do -- lie to their configure scripts about $build.

WJM. :-)  But as we're (finally!) abandoning the long-broken
- -mno-cygwin, I don't see why we can't dump this breakage as well.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkmAH8sACgkQpiWmPGlmQSPTwQCghn3w7Sr2ojNXQTdiizeIr9Qu
f8cAoPKk8R710du8gOFvFYDJuMAkGEUY
=7g0F
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Ralph Hempel]

Charles Wilson wrote:
> Pursuant to a discussion on the libtool list, I'm trying to get a feel
> for how many cygwin users rely on the cygwin environment to drive the
> *native* MinGW gcc compiler.  That is, incantations like this:

<snip>

I find myself bouncing around between cygwin and mingw because
each one helps me accomplish different tasks.

I use the Cygwin environment (including vim) for the actual
software development of embedded systems, and to host the
different gcc flavours needed for each target processor. There's
lots of great tools ready to go, and it's now possible
to drive the install from the command line, which makes it
easy to reproduce a specific workstation configuration.

Occasionally, I want to compile special tools that I can
redistribute without source, so I use mingw for that.

I have a build framework for embedded systems that I use for
all my projects - even PC based ones. If I'm compiling third
party software that comes with a makefile or autoconf script
then I'll use that.

Once you start designing makefiles that have to work with
multiple compiler versions and flags and include and library
paths, it gets complicated very quickly :-)

One reason I have not tried to drive the native MinGW compiler
is because of the path issues for includes and libraries. I
was worried that Cygwin includes and libraries would accidentally
get referenced.

Ralph

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Vincent R.]

On Wed, 28 Jan 2009 09:38:47 -0500, Ralph Hempel <rhempel@bmts.com> wrote:
> Charles Wilson wrote:
>> Pursuant to a discussion on the libtool list, I'm trying to get a feel
>> for how many cygwin users rely on the cygwin environment to drive the
>> *native* MinGW gcc compiler.  That is, incantations like this:
> 
> <snip>
> 
> I find myself bouncing around between cygwin and mingw because
> each one helps me accomplish different tasks.
> 
> I use the Cygwin environment (including vim) for the actual
> software development of embedded systems, and to host the
> different gcc flavours needed for each target processor. There's
> lots of great tools ready to go, and it's now possible
> to drive the install from the command line, which makes it
> easy to reproduce a specific workstation configuration.
> 
> Occasionally, I want to compile special tools that I can
> redistribute without source, so I use mingw for that.
> 
> I have a build framework for embedded systems that I use for
> all my projects - even PC based ones. If I'm compiling third
> party software that comes with a makefile or autoconf script
> then I'll use that.
> 
> Once you start designing makefiles that have to work with
> multiple compiler versions and flags and include and library
> paths, it gets complicated very quickly :-)
> 
> One reason I have not tried to drive the native MinGW compiler
> is because of the path issues for includes and libraries. I
> was worried that Cygwin includes and libraries would accidentally
> get referenced.
> 
> Ralph
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/

Actually I am using cygwin because there are many packages, adn a good
installer but I will 
switch completely to mingw if I could get the same.
Couldn't be possible to share more things between the two projects ?
I mean for instance share the cywgin installer that could allow people to
install cygwin and mingw
on two different places to avoid lib/path issues.
For instance :

C:\gnu\cygwin
C:\gnu\mingw
C:\gnu\home

They could share for instance the same home directory ...
Last time I tried to compile something with cygwin targeting mingw it just
failed...












--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Christopher Faylor]

On Wed, Jan 28, 2009 at 12:14:40AM -0600, Yaakov (Cygwin/X) wrote:
>Charles Wilson wrote:
>>This led to a suggestion that "--build=cygwin --host=mingw32" should
>>always be interpreted as: mingw32-gcc is a cygwin-hosted cross
>>compiler, NOT the native MinGW-project supported gcc (and if it IS the
>>native MinGW one, expect breakage).  I'm not sure such a sweeping
>>statement is accurate, or wise -- will that assumption break people's
>>exising (working) setups?
>
>If you're talking about configure gcc with those flags, then wouldn't
>that usually mean that you're cross-compiling a regular, native MinGW
>compiler?  If you want a cygwin-hosted MinGW cross-compiler, you should
>be using "--build=cygwin --host=cygwin --target=mingw32".  I would be
>hesitant to change the usual meaning of build/host just for
>Cygwin/MinGW; I don't think we need to add to the confusion that most
>people have about Cygwin.

Ditto.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Christopher Faylor]

On Wed, Jan 28, 2009 at 04:05:55PM +0100, Vincent R. wrote:
>Actually I am using cygwin because there are many packages, adn a good
>installer but I will 
>switch completely to mingw if I could get the same.
>Couldn't be possible to share more things between the two projects ?
>I mean for instance share the cywgin installer that could allow people to
>install cygwin and mingw
>on two different places to avoid lib/path issues.
>For instance :
>
>C:\gnu\cygwin
>C:\gnu\mingw
>C:\gnu\home
>
>They could share for instance the same home directory ...
>Last time I tried to compile something with cygwin targeting mingw it just
>failed...

The Cygwin installer is open source.  There is nothing stopping people from
using it.

There is no benefit to the Cygwin project in trying to adapt to some
other project's need but, in your above example, you could arrange your
own system to use those paths easily.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Roger Wells]

Charles Wilson wrote:
> Pursuant to a discussion on the libtool list, I'm trying to get a feel
> for how many cygwin users rely on the cygwin environment to drive the
> *native* MinGW gcc compiler.  That is, incantations like this:
>
> 1a)
> cygwin$ some-src-pkg/configure \
>   --build=i686-pc-cygwin --host=mingw32 \
>   CC=/c/MinGW/bin/gcc.exe \
>   CXX=/c/MinGW/bin/g++.exe \
>   NM=/c/MinGW/bin/nm.exe \
>   DLLTOOL=/c/MinGW/bin/dlltool.exe \
>   OBJDUMP=/c/MinGW/bin/objdump.exe \
>   LD=/c/MinGW/bin/ld.exe
>
> or possibly
>
> 1b)
> cygwin$ export PATH=/c/MinGW/bin:$PATH
> cygwin$ some-src-pkg/configure \
>   --build=i686-pc-cygwin --host=mingw32
>
> Note that this is *DIFFERENT* than installing a true cygwin-hosted
> mingw-target cross-compiler, and just doing
>
> 2)
> cygwin$ some-src-pkg/configure \
>   --build=i686-pc-cygwin --host=i686-pc-mingw32
>
> It is ALSO different than the (deprecated, unsupported,
> go-away-don't-bother-us) incantation:
>
> 3)
> cygwin$ some-src-pkg/configure \
>   --build=i686-pc-cygwin --host=i686-pc-mingw32 \
>   CFLAGS='-mno-cygwin'
>
> I hope this is considered on-topic here, because I'm interested in the
> uses of the cygwin environment itself.  I don't want reports of why it
> doesn't work, or how hard it is to get one of the incantations above to
> work.  I just want to get an idea of how many people are currently,
> actually, successfully, doing something like 1a) or 1b) above.
>
>   
Our development group uses "native" MinGW every day with the Cygwin bash 
shell as the center of operations.  
I believe that we are over ten years into this at this point
Our build environment uses Serena Configuration Builder and PVCS, but I 
can feel a more standard unixish (autoconf,
automake, etc) environment coming in as well.  I also use Cygwin to 
develop using Embedded C++, Visual C++ by starting bash
via a windows batch file that sets the "BASHENV" environment variable 
to  another script, eg .mingwrc, that  sets the build environment
specifically ensuring in this case that MinGW's gcc, etc is ahead of 
Cygwin's in the PATH.
> --
> Chuck
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>
>   

-- 
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells@saic.com


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Claude Sylvain]

Charles Wilson wrote:

 >
 > Pursuant to a discussion on the libtool list, I'm trying to get a feel
 > for how many cygwin users rely on the cygwin environment to drive the
 > *native* MinGW gcc compiler.
 >

- I currently use Cygwin for cross-platform development of software and
   firmware.

- I use Msys/MinGW for development of Windows software.


- I plan to move from Msys/MinGW to Cygwin/MinGW to develop Windows
   software, soon.


Claude.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Reini Urban]

Charles Wilson schrieb:
> I just want to get an idea of how many people are currently,
> actually, successfully, doing something like 1a) or 1b) above.

I never do serious cross-compiling from or to mingw in a cygwin shell. 
When testing mingw I do it from cmd.exe and the mingw toolkit and no 
cygwin in the path.
-- 
Reini

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Greg Chicares]

On 2009-01-28 05:28Z, Charles Wilson wrote:
> Greg Chicares wrote:
>> On 2009-01-28 02:21Z, Charles Wilson wrote:
>>> Pursuant to a discussion on the libtool list, I'm trying to get a feel
>>> for how many cygwin users rely on the cygwin environment to drive the
>>> *native* MinGW gcc compiler.
>> 
>> I use the native MinGW compiler in a Cygwin environment,
>> successfully, many hours every day.
> 
> A few additional questions, then:
> 
> Do you use gnu-style configured projects (autoconf, automake, libtool,
> all that?) -- or some other build framework?

Yes. I use autotools to build "native" versions of libraries I need,
in particular libxml2, libxslt, and wxwidgets. As an example, for
libxml2, here's the crucial part:

[snippet begins]
# For 'host' and 'build' configure options, see:
#   http://cygwin.com/ml/cygwin/2002-01/msg00837.html

# '--disable-dependency-tracking' is required with the MinGW toolchain
# in a Cygwin shell, to prevent a catastrophic dependency-tracking
# failure. Apparently the problem is colons in header paths, e.g.:
#   c:/MinGW-20050827/bin/../lib/gcc/mingw32/3.4.4/include/stddef.h:
# which elicit fatal errors such as this:
#   .deps/DOCBparser.Plo:1: *** multiple target patterns.  Stop.

common_options := \
  --build=i686-pc-mingw32 \
  --host=i686-pc-mingw32 \
  --disable-dependency-tracking \
[...]
  CC='$(mingw_bin_dir)/gcc' \
  LD='$(mingw_bin_dir)/ld' \
  LDFLAGS='-lws2_32' \
[snippet ends]

[It may seem weird that I use a *makefile* to invoke autotools;
maybe that's just a personal quirk because I'm comfortable with
make's intricacies, whereas someone else might write a shell
script for that.] As for --build and --host, the rationale for
  --build=i686-pc-mingw32 \
  --host=i686-pc-mingw32 \
is just that I copied them from the old message cited above
  http://cygwin.com/ml/cygwin/2002-01/msg00837.html
and they do seem to work; I don't have enough understanding of
autotools to explain them any better than that.

I can live with '--disable-dependency-tracking' because I rarely
modify the sources; if I ever do, I can 'make clean' and rebuild
them from scratch.

An incidental oddity is that the technique above produces
  cygxml2-2.dll
  cygxslt-1.dll
  cygwxmsw28_gcc_344-0.dll
with 'cyg-' instead of 'lib-'. AFAICT, this doesn't matter
because the MinGW linker looks for both prefixes. I happen to
have Cygwin's version of some dlls as well as my own, e.g.:
  $where cygxml2-2.dll
  /opt/lmi/local/bin/cygxml2-2.dll
  /usr/bin/cygxml2-2.dll
  /bin/cygxml2-2.dll
but I specify my own '-L' path to the linker. Well, actually, I
guess that doesn't matter: the MinGW linker wouldn't look here:
  C:\cygwin\bin\cygxml2-2.dll
by default anyway.

For my own code that uses libraries built as above, I personally
use handwritten makefiles. But my project is autotoolized, and I
have coworkers who use auto* files to build it, instead of my
handwritten makefiles.

> Do you use cygwin's make (which version?), mingw32-make, or perhaps a
> cygwin build of msys's csmake/cpmake?

I use only Cygwin's make-3.81:

$which make
/usr/bin/make
$make --version
GNU Make 3.81
[...]
This program built for i686-pc-cygwin

> Do you use gcc's -M* options for generating dependencies -- with
> mingw-gcc, these rules will be in dos format and cygwin-make-3.81
> doesn't grok them?

Yes. With '-MD', I'd have the problem you mention, but I'd fix that
with 'sed'. (It might be smarter to use 'cygpath', but I've been
using 'sed' for this since before the '-M*' options became stable.)

With '-MMD', however, I can skip the 'sed' step and everything just
works. For instance, I get

  fenv_lmi.o fenv_lmi.o: /lmi/src/lmi/fenv_lmi.cpp \
    /lmi/src/lmi/fenv_lmi.hpp /lmi/src/lmi/config.hpp ...

Perhaps that's just a happy consequence of using
  mount -f -s -b "C:/lmi" "/lmi"
  mount -f -s -b "C:/opt/lmi" "/opt/lmi"
(which IIRC is the sort of "identity mount" Danny uses to build gcc)
and keeping all my stuff in those two directories.

> What about creating static libraries? If you use mingw's ar.exe, do you
> use explicit `cygpath` rules to convert unix paths to the DOS paths that
> version of ar can understand, or some other technique?

I don't build third-party libraries as static. When I build my own
static libraries, I use MinGW's 'ar', but the command line is just
  /MinGW_/bin/ar -rus   liblmi.a convenience.o exception.o [...]
where all the '.o' files are in the directory where I invoke 'ar'.

I don't use 'cygpath' at all, anywhere. Using the "identity mount"
technique, and always specifying paths with forward slashes (which
virtually all msw programs accept), covers almost everything I need.
For 'CPP -MD', I'd use 'sed' as mentioned above. I occasionally use
a couple of compilers other than gcc, and where they don't grok
forward slashes, I use a C++ program as a wrapper that does the
translation.

> For a hint about why I started this thread, and why I am asking these
> questions, see
> http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00163.html
> -- especially my failures with
> 
> $ export PATH="/c/MinGW/bin:$PATH"
> $ ../libtool/configure --build=i686-pc-cygwin --host=mingw32

In particular, in that message you say:

| Finally -- there's one problem without an obvious fix: cygwin's
| make no longer supports dos-style paths (in target rules, which isn't the problem
| here), nor in .deps files (which IS the problem). The .deps files are generated
| by (mingw native) gcc, and therefore contain DOS-style paths.

which is the problem I skip over via '--disable-dependency-tracking'
when building libxml2 (above). MinGW gcc with '-MD' gives, e.g.:

foo.o: \
  C:/MinGW-20050827/bin/../lib/gcc/mingw32/3.4.4/../../../../include/stdio.h \

and maybe this problem would be solved if it could drop the "C:" part,
but that's no good because it would break compiles run on a "D:" drive.

> This led to a suggestion that "--build=cygwin --host=mingw32" should
> always be interpreted as: mingw32-gcc is a cygwin-hosted cross compiler,
> NOT the native MinGW-project supported gcc (and if it IS the native
> MinGW one, expect breakage). I'm not sure such a sweeping statement is
> accurate, or wise -- will that assumption break people's exising
> (working) setups?

I use '--build=i686-pc-mingw32 --host=i686-pc-mingw32'. Here:
  http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00193.html
you say that's lying to 'configure', but you also observe that
I'm in excellent company. I'd be dismayed if that broke.

As for the build!=host case '--build=cygwin --host=mingw32',
I could try rebuilding my stuff that way if you think an extra
datapoint would help. I probably tried that at some time in the
past, but can't remember whether it worked.

As for this sweeping statement:
  http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00191.html
| I don't think we should try to support the scenario where the MinGW gcc,
| exactly as supplied by the MinGW project, is executed from within Cygwin.
which I believe you're trying to counter: as evidence that at
least some people in the real world care about this, you could
cite the first paragraph here:
  http://lists.nongnu.org/archive/html/lmi/2007-07/msg00008.html
which echoes some of the things you said on libtool-patches,
and the applicable part of this message:
  http://lists.nongnu.org/archive/html/lmi/2007-11/msg00007.html
| Here's my rationale for some of the technical decisions. First of
| all, at least for now, I've chosen to use a MinGW toolchain in a
| Cygwin environment. [...]


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Kai Raphahn]

Charles Wilson wrote:

> Pursuant to a discussion on the libtool list, I'm trying to get a feel
> for how many cygwin users rely on the cygwin environment to drive the
> *native* MinGW gcc compiler.  That is, incantations like this:

[snip]

> I hope this is considered on-topic here, because I'm interested in the
> uses of the cygwin environment itself.  I don't want reports of why it
> doesn't work, or how hard it is to get one of the incantations above to
> work.  I just want to get an idea of how many people are currently,
> actually, successfully, doing something like 1a) or 1b) above.

None of then above... MOST of the time I use a true self-compiled cross
compiler that resides in /mingw and use the cygwin environment [1].

I only use a native MinGW and cygwin when dealing with more exotic build
systems like bjam for boost or things that were desined for the
mingw32-make.


Kai

[1] ...well aside from uname. When using my cross compiler I start a script
that resets some enviroment variables and switches to a self-written uname
that claims a MSYS/MinGW Enviroment. That way I can run something like that

 --build=i686-pc-mingw32 --host=i686-pc-mingw32

under cygwin without the hiccups of true cross-compiling (running
executables when a configure does tests).

That way I can use a patched cygport that resides in /mingw/bin, the cygwin
setup.exe and get a nice sum of packages.. enough to compile gtk, xchat,
gimp, mplayer and some others.

Its a rather strange enviroment I admit... and thew new libtool 2.0 won't
work too. It did start a windows-command shell when linking that did nothing
but idling in my process list.

I did use MSYS for quite some time, but the cygwin enviroment is better
maintained for my needs.

-- 
<Unseen2> Warum hat eigentlich noch niemand Electrocution-via-IP implementiert?
<Onkel_Kai> ECP -> electric-chair-protocol
<Hunni> Stab-over-IP hört sich immer noch am besten an

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Charles Wilson]

Greg Chicares wrote:
> On 2009-01-28 05:28Z, Charles Wilson wrote:

First, thanks for your detailed response. It was very helpful.

>> Do you use gnu-style configured projects (autoconf, automake, libtool,
>> all that?) -- or some other build framework?
> 
> Yes. I use autotools to build "native" versions of libraries I need,
> in particular libxml2, libxslt, and wxwidgets. As an example, for
> libxml2, here's the crucial part:
...(reordered, below)...
> I can live with '--disable-dependency-tracking' because I rarely
> modify the sources; if I ever do, I can 'make clean' and rebuild
> them from scratch.
...
> I use only Cygwin's make-3.81:
...
[ stuff concerning -M*, including notations that you use "identity" mounts ]

Interesting. So you have to be quite careful about how your system is
configured: without identity mounts, it *will* break. If you (or any
package you build) uses -M* (except for -MMD) then it *will* break, and
-MMD only works if all paths in your build process are relative -- or
(again) if you have identity mounts. (And identity mounts are not
possible if you routinely use more than one drive).

This is already quite fragile.

>> What about creating static libraries?...
>
> I don't build third-party libraries as static. When I build my own
> static libraries, I use MinGW's 'ar', but the command line is just
>   /MinGW_/bin/ar -rus   liblmi.a convenience.o exception.o [...]
> where all the '.o' files are in the directory where I invoke 'ar'.

Once again -- a carefully managed situation where all paths are
explicitly relative.

> An incidental oddity is that the technique above produces
>   cygxml2-2.dll
>   cygxslt-1.dll
>   cygwxmsw28_gcc_344-0.dll
> with 'cyg-' instead of 'lib-'. AFAICT, this doesn't matter
> because the MinGW linker looks for both prefixes. I happen to
> have Cygwin's version of some dlls as well as my own, e.g.:
>   $where cygxml2-2.dll
>   /opt/lmi/local/bin/cygxml2-2.dll
>   /usr/bin/cygxml2-2.dll
>   /bin/cygxml2-2.dll
> but I specify my own '-L' path to the linker. Well, actually, I
> guess that doesn't matter: the MinGW linker wouldn't look here:
>   C:\cygwin\bin\cygxml2-2.dll
> by default anyway.

Oh, geez. That's really bad.  The whole POINT of cygwin using a special
prefix for its DLLs is so that they won't be found by "accident" when
the Windows Runtime Loader is loading a mingw app.  That is,

  mingw-foo.exe <-- (mingw) libz-1.dll
  cygwin-foo.exe <-- (cygwin) cygz-1.dll

So in the first case, the WRL sees that mingw-foo.exe needs a DLL named
"libz-1.dll" and searches (according to certain rules) for it. Because
all (ok, almost all) cygwin DLLs begin with 'cyg', none of them will be
named "libz-1.dll" -- so mingw-foo will work properly even if cygwin's
bin directory comes before (wherever libz-1.dll is) in the $PATH.

However, if instead you have:

  mingw-foo.exe <-- (mingw) cygz-1.dll
  cygwin-foo.exe <-- (cygwin) cygz-1.dll

Then either mingw-foo.exe or cygwin-foo.exe may break, depending on
which cygz-1.dll is found first in $PATH. (You might assume that if
mingw-foo.exe is in the same directory as the "mingw" cygz-1.dll, and
cygwin-foo.exe is in the same directory as the "cygwin" cygz-1.dll, that
the WRL would never be confused and things would always work, because
$PATH is never searched. You'd be wrong: what if mingw-foo.exe is a very
long-running process. So, it's in memory, along with a mapped copy of
the (mingw) cygz-1.dll. Now, you launch cygwin-foo.exe. The WRL is
smart: it sees that it needs a "cygz-1.dll" -- but wait! it already has
one loaded in memory. All it needs to do is map the readonly parts of
the (mingw) cygz-1.dll into cygwin-foo.exe's address space, and call the
dll initialization routines.

But that's the wrong cygz-1.dll. Bang. Dead.

Note that my concerns have little to do with what happens at link-time;
these are *run-time* problems.

[Aside: the mingw linker does NOT search for cyg*dll. It searches for:

          libxxx.dll.a
          xxx.dll.a
          libxxx.a
          xxx.lib
          libxxx.dll
          xxx.dll

because the mingw gcc spec file does NOT include --dll-search-prefix.
However, if the libxxx.dll.a that it DOES find specifies "I'm an import
library for cygxxx.dll" well, then, that's what the exe will tell the
Windows Runtime Loader that it needs.  cygwin's gcc spec file specifies
--dll-search-prefix=cyg, so its ld searches for:

          libxxx.dll.a
          xxx.dll.a
          libxxx.a
          xxx.lib
          cygxxx.dll
          libxxx.dll
          xxx.dll

But this usually doesn't matter, because you tell gcc -L/some/libdir/,
where it only finds *.dll.a and *.a, not -L/some/bindir where the
*.dll's live.]

What confuses me, tho, is this: if your package KNOWS (because you told
it) that $build and $host are mingw, then WHY is your libtool using
cygwin rules to generate the DLL name? But that's something for another
thread.

>> This led to a suggestion that "--build=cygwin --host=mingw32" should
>> always be interpreted as: mingw32-gcc is a cygwin-hosted cross compiler,
>> NOT the native MinGW-project supported gcc (and if it IS the native
>> MinGW one, expect breakage). I'm not sure such a sweeping statement is
>> accurate, or wise -- will that assumption break people's exising
>> (working) setups?
> 
> I use '--build=i686-pc-mingw32 --host=i686-pc-mingw32'. Here:
>   http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00193.html
> you say that's lying to 'configure', but you also observe that
> I'm in excellent company. I'd be dismayed if that broke.

Well, as I point out above: it's already very fragile, and requires a
great deal of careful setup to get it to work "correctly" (if generating
DLLs with the wrong name can be considered "correct").

I wouldn't want to gratuitously break this usage, but I am leaning
towards endorsing the suggestion that it's bad to lie to your toolchain.
However, if you REALLY want to do so, and assume all the risk of
breakage/failure/hairloss/heartburn, then...set these [*] environment
variables before you ./configure, and then cross your fingers...

> As for the build!=host case '--build=cygwin --host=mingw32',
> I could try rebuilding my stuff that way if you think an extra
> datapoint would help. I probably tried that at some time in the
> past, but can't remember whether it worked.

That would be a useful data point, but even if it worked, most testsuite
frameworks are smart enough to NOT try to run their tests in a
cross-build situation. One of Danny's (and TDM'a
http://www.tdragon.net/recentgcc/) reasons for "lying" the way they do
is that the build machinery "believes" it is a native build, so it goes
ahead and runs the testsuite.

> As for this sweeping statement:
>   http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00191.html
> | I don't think we should try to support the scenario where the MinGW gcc,
> | exactly as supplied by the MinGW project, is executed from within Cygwin.
> which I believe you're trying to counter: as evidence that at
> least some people in the real world care about this, you could
> cite the first paragraph here:
>   http://lists.nongnu.org/archive/html/lmi/2007-07/msg00008.html
> which echoes some of the things you said on libtool-patches,
> and the applicable part of this message:
>   http://lists.nongnu.org/archive/html/lmi/2007-11/msg00007.html
> | Here's my rationale for some of the technical decisions. First of
> | all, at least for now, I've chosen to use a MinGW toolchain in a
> | Cygwin environment. [...]

Thanks for those references; I will keep them in mind as we go forward.

[*] Here's what I'm thinking: right now (libtool-2.2.6+), the
--build=mingw --host=mingw situation when build is REALLY cygwin, is
broken, because (a) we no longer have the wrapper script when $host is
win32ish, only a wrapper exe (b) as it stands now, this wrapper exe will
ONLY have the correct ($host, not $build) path to the real exe when
mingw->mingw native, cygwin->cygwin native, or unix->mingw cross.  We
NEED to support a wider universe, because so many mingw and cygwin
clients use cross environments of some kind, beyond those currently
working: unix->cygwin, cygwin->mingw(non-lying), cygwin->mingw(lying?).

The most straightforward assumption is that cygwin->mingw is, well,
cygwin->mingw. That is, libtool should assume that the information it is
given about the $build environment (via config.guess or via --build) is
truthful. So, the proposed patch will support (in addition to c->c
native, m->m native, u->m cross), u->c cross, c->m (non-lying).

With a slight additional change, the c->m (lying) case can probably be
made to work as well, but it is already so fragile, requiring identity
mounts and avoid -M options, that I can't see it continuing as a
supported option. Which is not to say that it is officially supported
now -- it's just that several high-profile people do it, because it
(happens to) work...mostly. Kinda. Right now. With libtool older than
2.2.(4?)

So, I'm thinking we can kinda-sorta enable it to continue to mostly work
(caveat emptor, etc etc) by making the following libtool variables cached:

lt_cv_to_host_path_cmd
lt_cv_to_host_pathlist_cmd

Then, folks like you, TDM, Danny, etc, can do

cygwin$ export lt_cv_to_host_path_cmd=func_cygwin_to_mingw_path_convert
cygwin$ export
lt_cv_to_host_pathlist_cmd=func_cygwin_to_mingw_pathlist_convert

before

cygwin$ ../src/configure --build=mingw32 --host=mingw32 ...

Ordinarily, the above configure incantation would result in libtool (as
proposed) using func_msys_to_mingw_path[list]_convert -- which is
clearly wrong in this case, because func_msys_to_mingw_path_convert
ain't gonna work right in a $build environment that is actually cygwin.
 So, override it with the correct conversion functions -- and your
wrapper exe's will have the correct paths.

Setting autoconf cached variables is clearly an esoteric proposition,
requiring detailed knowledge of libtool internals (or the URL of this
post).  But so does "knowing" why you need identity mounts, or that you
have to use --disable-dependency-tracking for arcane path-handling
reasons.  I can't see that requiring to env vars is any worse than all that.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Greg Chicares]

On 2009-01-29 05:08Z, Charles Wilson wrote:
> Greg Chicares wrote:
>> On 2009-01-28 05:28Z, Charles Wilson wrote:

Forgive my delay in thanking you for taking so much time to
point out the many issues with what I'm doing. Perhaps the
worst problem was this:

>> An incidental oddity is that the technique above produces
>>   cygxml2-2.dll
>>   cygxslt-1.dll
>>   cygwxmsw28_gcc_344-0.dll
>> with 'cyg-' instead of 'lib-'.

[snip details of the merry dance whereby I avoided catastrophe,
at least for the moment, even if just by luck]

> Oh, geez. That's really bad.

[snip explanation of how much worse it is than I had imagined]

>> I use '--build=i686-pc-mingw32 --host=i686-pc-mingw32'.

I have repented of that.

>> As for the build!=host case '--build=cygwin --host=mingw32',
>> I could try rebuilding my stuff that way if you think an extra
>> datapoint would help. I probably tried that at some time in the
>> past, but can't remember whether it worked.
> 
> That would be a useful data point,

'--build=cygwin --host=mingw32' works, at least for libxml2,
libxslt, and wxwidgets. And the libraries are prefixed with
'lib' instead of 'cyg', which avoids some awful problems.

I took care to wipe out every vestige of the old 'cyg'
libraries first, then rebuilt them and my app from scratch.
I've tested the app, and everything works fine.

> but even if it worked, most testsuite
> frameworks are smart enough to NOT try to run their tests in a
> cross-build situation. One of Danny's (and TDM'a
> http://www.tdragon.net/recentgcc/) reasons for "lying" the way they do
> is that the build machinery "believes" it is a native build, so it goes
> ahead and runs the testsuite.

Acknowledged. Probably the ideal solution is to switch to a
true cross-MinGW compiler when that becomes available. I can
avoid updating any autotools package until then, so I don't
need to worry about any recent changes breaking my present
process.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Charles Wilson]

Charles Wilson wrote:
[describe "old" libtool behavior; what I called "current gcc libtool"]
>  1) creates both a wrapper script foo and wrapper exe foo.exe in the
> build directory, and also (?) a copy of the wrapper script in .libs/
>  2) the wrapper exe execs the wrapper script via $SHELL
>  3) the wrapper script handles all the $PATH manipulations, and
> locates/execs the "real" exe

[contrast new libtool-git-ToT behavior]
> And that's the problem. I have a hunch that *right now*, if we dropped
> in git-master-ToT libtool into gcc, your configure incantation would
> fall over dead, because every executable's wrapper script (if built
> using libtool) would have the "wrong" format of path/to/real/exe inside
> _spawn("...") -- unless we dodged the bullet, as described above.

Wierd. It's been a while since I updated my local svn tree of gcc. It
finally finished, and I see that, in fact, current gcc trunk includes a
much newer version of libtool than I thought (2008-09-26==2.2.6ish, not
2007-03-18). So, in reality, *current* gcc libtool has the "new" behavior.

If that's working for you, Danny, then I guess gcc really did "dodge the
bullet" -- maybe libtool is never used in linking applications or test
progs within the gcc tree, so it's a moot point /for gcc/?

But, all the worries I listed still apply for *other* packages that
someone might want to compile using --build=mingw --host=mingw, when
$build is actually cygwin.  But it'd be wonderful to avoid all that
worry for the src/ tree!

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Charles Wilson]

Danny Smith wrote:
> The reasons I use "--build=mingw32 --host=mingw32 --target=mingw32" 
> when building gcc are
> 1) I have, perhaps mistakenly, assumed that "--build=" referred to the OS of the compiler,
> not the ethnicity of the shell.

I've assumed it was describing the entire build environment: compiler,
yes, linker, yes, but also the surrounding utilities involved in the
configuration/compilation process. That's why config.guess uses uname,
not $CC -version.

I guess that's the nub of the discussion we're having right now: what
does it mean when the $build compiler/toolchain is A, but all the other
$build tools are B? In seems fragile to assume /either/ build==A, /or/
build==B.

> 2) my build gcc is a mingw32 gcc, and unlike a cygwin-hosted gcc, doesn't understand
> symlinks.  "--build=cygwin32"  would suggest that the native gcc understands symlinks.
> Ditto for my binutil and gdb apps which do not depend on cygwin.

Good point. See next para.

> 3) specifying "--host=mingw32 --target=mingw32" usually works just fine too (within a
> cygwin bash shell), for most projects, as long as there are no assumptions about symlinks.

Hmmm. When you specify host and target (obviously we're now talking
about configuring/building a compiler or part of a compiler toolchain,
and not simply Q.Random.Utility.Package; those don't have --target),
$build is set implicitly by analyzing the current OS (c.f. config.guess,
uname, etc).  So, in effect, you're saying that --build=cygwin
--host=mingw32 --target=mingw32 works?

Again hmmm. So that must mean that (legions of slaving GCC developers)
have already set things up in the gcc tree so that symlinks aren't
used...ever? Even when $build supports them?

> 4) "--build=mingw32 --host=mingw32 --target=mingw32"  always seemed to be a natural way to
> do a bootstrap.

Certainly. If *everything* about the build environment was, in fact,
"mingw" (or, actually, msys in its normal "don't mind me; I'm
mingw...really, I am!" mode).

But when the toolchain is mingw, but the rest of the $build env is
cygwin? Not quite so natural.

> I don't set any special environment variables before I "bash ./config.sh" from a DOS
> prompt (my everday path just put C:/mingw/bin in front of C:/cygwin/bin) and I don't cross
> my fingers because I know it has worked for 10 years or so.

Yes, I know: you're one of the first people I thought of when this
subject came up on the libtool list. I *really* want to make sure that
things keep working for you, in the way you expect them to (with maybe
only a small tweak to your build.sh <g>)

But I worry that things are (or will soon be) broken already.  gcc
currently has a snapshot of development libtool from 2007-03-18, with
several fixes backported from more recent git. So, presently, the
libtool used by gcc does the following, when building an exe that
depends on an uninstalled shared library [*]:
 1) creates both a wrapper script foo and wrapper exe foo.exe in the
build directory, and also (?) a copy of the wrapper script in .libs/
 2) the wrapper exe execs the wrapper script via $SHELL
 3) the wrapper script handles all the $PATH manipulations, and
locates/execs the "real" exe

[*] Doesn't this description apply to most of the tools, and many of the
testsuite apps?  Now, if libtool is only used to build the libs, and
gcc's Makefiles/test harnesses handle everything else without the use of
libtool or its wrapper script/wrapper exe system...then whew! maybe we
dodged a bullet!

[**] Note the context switches involved in old libtool (current gcc
libtool): you're in $build, and you launch the $host wrapper exe, which
launches the $build $SHELL, which executes the wrapper script in a
$build context, which launches the $host "real" exe.

This 1-2-3 step process works fine in all the scenarios mentioned;
mainly because the "difficult bits" are handled by $SHELL (of whatever
flavor) and its underlying runtime (be it cygwin [***], or msys[****],
or whatever).

[***] cygwin's exec() implementation translates many environment
variables from posix to win32 format, when the target of the exec() is a
non-cygwin application. So, when //bash// execs the real exe, under the
hood cygwin translates $PATH. Also, cygwin's exec() implementation
translates the unix path-to-real.exe before (eventually) invoking
CreateProcess with a win32 path-to-real.exe.

[****] msys's bash works similarly to cygwin, expecially its interaction
with the underlying posix dll's exec implementation.

But...this 1-2-3 process never worked in cygwin-1.5 if
CYGWIN=transparent_exe (more at the link, below).

However, in cygwin-1.7 this has significant problems; the old (optional)
transparent_exe behavior is now the default. This means that having both
a wrapper script 'foo' and a wrapper exe 'foo.exe' in the same directory
 is very bad news.
See this thread:
libtool vs. transparent_exe [Was: [ITP] util-linux]
http://sources.redhat.com/ml/cygwin/2006-03/msg00148.html

And this one a year later:
.exe magic
http://sources.redhat.com/ml/cygwin/2007-04/msg00515.html

Which eventually led to the behavior that libtool 2.2.0+ exhibits: it
now generates only the wrapper .exe (there's still a version of the
wrapper script in .libs/, but that's only used internally by libtool --
"sourced" back in). The wrapper .exe now directly execs the "real"
executable -- and manipulates **env itself.  However:

The wrapper .exe is a $host (not $build) application, just like the
"real" .exe. This means that libtool must be smart enough to convert new
$PATH settings from $build format to $host format, when writing the
source code for the wrapper exe. It also must convert the
path/to/real/exe from $build format to $host format, so that exec("")
has "the right stuff" for $host's exec() implementation -- or, in the
case of $host=mingw, _spawn().  In short, libtool has to manually
perform all the grunt work that used to be handled (or, with gcc's
current libtool, is now handled) by exec("$SHELL wrapper.script") via
the magic of the $SHELL and its posix runtime library (cygwin, msys) on
$build.

And that's the problem. I have a hunch that *right now*, if we dropped
in git-master-ToT libtool into gcc, your configure incantation would
fall over dead, because every executable's wrapper script (if built
using libtool) would have the "wrong" format of path/to/real/exe inside
_spawn("...") -- unless we dodged the bullet, as described above.

But even if we dodged the bullet for gcc, other packages which use
--build=mingw32 --host=mingw32 when $build is actually cygwin will NOT
be so lucky. So, *something* has to be fixed...

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: RFD: cygwin + *native* MinGW compiler

[Danny Smith]

At:
http://www.cygwin.com/ml/cygwin/2009-01/msg00848.html

Charles Wilson said:
Greg said
>>
>>I use '--build=i686-pc-mingw32 --host=i686-pc-mingw32'. Here:
>>  http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00193.html
>>you say that's lying to 'configure', but you also observe that
>>I'm in excellent company. I'd be dismayed if that broke.
>
>Well, as I point out above: it's already very fragile, and.requires a
>great deal of careful setup to get it to work "correctly" (if generating
>DLLs with the wrong name can be considered "correct").
>
>I wouldn't want to gratuitously break this usage, but I am leaning
>towards endorsing the suggestion that it's bad to lie to your toolchain.
>However, if you REALLY want to do so, and assume all the risk of
>breakage/failure/hairloss/heartburn, then...set these [*] environment
>variables before you ./configure, and then cross your fingers...

The reasons I use "--build=mingw32 --host=mingw32 --target=mingw32" 
when building gcc are
1) I have, perhaps mistakenly, assumed that "--build=" referred to the OS of the compiler,
not the ethnicity of the shell.
2) my build gcc is a mingw32 gcc, and unlike a cygwin-hosted gcc, doesn't understand
symlinks.  "--build=cygwin32"  would suggest that the native gcc understands symlinks.
Ditto for my binutil and gdb apps which do not depend on cygwin.
3) specifying "--host=mingw32 --target=mingw32" usually works just fine too (within a
cygwin bash shell), for most projects, as long as there are no assumptions about symlinks.

4) "--build=mingw32 --host=mingw32 --target=mingw32"  always seemed to be a natural way to
do a bootstrap.

I don't set any special environment variables before I "bash ./config.sh" from a DOS
prompt (my everday path just put C:/mingw/bin in front of C:/cygwin/bin) and I don't cross
my fingers because I know it has worked for 10 years or so.

Danny


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/