* Re: RFD: cygwin + *native* MinGW compiler
@ 2009-01-29 9:52 Danny Smith
2009-01-29 12:29 ` Charles Wilson
0 siblings, 1 reply; 22+ messages in thread
From: Danny Smith @ 2009-01-29 9:52 UTC (permalink / raw)
To: Cygwin
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/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-29 9:52 RFD: cygwin + *native* MinGW compiler Danny Smith @ 2009-01-29 12:29 ` Charles Wilson 2009-01-29 15:13 ` Charles Wilson 0 siblings, 1 reply; 22+ messages in thread From: Charles Wilson @ 2009-01-29 12:29 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-29 12:29 ` Charles Wilson @ 2009-01-29 15:13 ` Charles Wilson 0 siblings, 0 replies; 22+ messages in thread From: Charles Wilson @ 2009-01-29 15:13 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* RFD: cygwin + *native* MinGW compiler @ 2009-01-28 4:38 Charles Wilson 2009-01-28 5:29 ` Christopher Faylor ` (7 more replies) 0 siblings, 8 replies; 22+ messages in thread From: Charles Wilson @ 2009-01-28 4:38 UTC (permalink / raw) To: Cygwin Mailing List 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 4:38 Charles Wilson @ 2009-01-28 5:29 ` Christopher Faylor 2009-01-28 6:14 ` Warren Young ` (6 subsequent siblings) 7 siblings, 0 replies; 22+ messages in thread From: Christopher Faylor @ 2009-01-28 5:29 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 4:38 Charles Wilson 2009-01-28 5:29 ` Christopher Faylor @ 2009-01-28 6:14 ` Warren Young 2009-01-28 6:55 ` Greg Chicares ` (5 subsequent siblings) 7 siblings, 0 replies; 22+ messages in thread From: Warren Young @ 2009-01-28 6:14 UTC (permalink / raw) To: Cygwin-L 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 4:38 Charles Wilson 2009-01-28 5:29 ` Christopher Faylor 2009-01-28 6:14 ` Warren Young @ 2009-01-28 6:55 ` Greg Chicares 2009-01-28 7:18 ` Charles Wilson 2009-01-28 15:15 ` Ralph Hempel ` (4 subsequent siblings) 7 siblings, 1 reply; 22+ messages in thread From: Greg Chicares @ 2009-01-28 6:55 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 6:55 ` Greg Chicares @ 2009-01-28 7:18 ` Charles Wilson 2009-01-28 9:05 ` Yaakov (Cygwin/X) 2009-01-28 23:08 ` Greg Chicares 0 siblings, 2 replies; 22+ messages in thread From: Charles Wilson @ 2009-01-28 7:18 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 7:18 ` Charles Wilson @ 2009-01-28 9:05 ` Yaakov (Cygwin/X) 2009-01-28 11:10 ` Charles Wilson 2009-01-28 15:19 ` Christopher Faylor 2009-01-28 23:08 ` Greg Chicares 1 sibling, 2 replies; 22+ messages in thread From: Yaakov (Cygwin/X) @ 2009-01-28 9:05 UTC (permalink / raw) To: cygwin -----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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 9:05 ` Yaakov (Cygwin/X) @ 2009-01-28 11:10 ` Charles Wilson 2009-01-28 11:21 ` Yaakov (Cygwin/X) 2009-01-28 15:19 ` Christopher Faylor 1 sibling, 1 reply; 22+ messages in thread From: Charles Wilson @ 2009-01-28 11:10 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 11:10 ` Charles Wilson @ 2009-01-28 11:21 ` Yaakov (Cygwin/X) 0 siblings, 0 replies; 22+ messages in thread From: Yaakov (Cygwin/X) @ 2009-01-28 11:21 UTC (permalink / raw) To: cygwin -----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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 9:05 ` Yaakov (Cygwin/X) 2009-01-28 11:10 ` Charles Wilson @ 2009-01-28 15:19 ` Christopher Faylor 1 sibling, 0 replies; 22+ messages in thread From: Christopher Faylor @ 2009-01-28 15:19 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 7:18 ` Charles Wilson 2009-01-28 9:05 ` Yaakov (Cygwin/X) @ 2009-01-28 23:08 ` Greg Chicares 2009-01-29 9:44 ` Charles Wilson 1 sibling, 1 reply; 22+ messages in thread From: Greg Chicares @ 2009-01-28 23:08 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 23:08 ` Greg Chicares @ 2009-01-29 9:44 ` Charles Wilson 2009-02-11 2:34 ` Greg Chicares 0 siblings, 1 reply; 22+ messages in thread From: Charles Wilson @ 2009-01-29 9:44 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-29 9:44 ` Charles Wilson @ 2009-02-11 2:34 ` Greg Chicares 0 siblings, 0 replies; 22+ messages in thread From: Greg Chicares @ 2009-02-11 2:34 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 4:38 Charles Wilson ` (2 preceding siblings ...) 2009-01-28 6:55 ` Greg Chicares @ 2009-01-28 15:15 ` Ralph Hempel 2009-01-28 15:18 ` Vincent R. 2009-01-28 16:08 ` Roger Wells ` (3 subsequent siblings) 7 siblings, 1 reply; 22+ messages in thread From: Ralph Hempel @ 2009-01-28 15:15 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 15:15 ` Ralph Hempel @ 2009-01-28 15:18 ` Vincent R. 2009-01-28 15:26 ` Christopher Faylor 0 siblings, 1 reply; 22+ messages in thread From: Vincent R. @ 2009-01-28 15:18 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 15:18 ` Vincent R. @ 2009-01-28 15:26 ` Christopher Faylor 0 siblings, 0 replies; 22+ messages in thread From: Christopher Faylor @ 2009-01-28 15:26 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 4:38 Charles Wilson ` (3 preceding siblings ...) 2009-01-28 15:15 ` Ralph Hempel @ 2009-01-28 16:08 ` Roger Wells 2009-01-28 16:40 ` Claude Sylvain ` (2 subsequent siblings) 7 siblings, 0 replies; 22+ messages in thread From: Roger Wells @ 2009-01-28 16:08 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 4:38 Charles Wilson ` (4 preceding siblings ...) 2009-01-28 16:08 ` Roger Wells @ 2009-01-28 16:40 ` Claude Sylvain 2009-01-28 17:22 ` Reini Urban 2009-01-28 23:47 ` Kai Raphahn 7 siblings, 0 replies; 22+ messages in thread From: Claude Sylvain @ 2009-01-28 16:40 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 4:38 Charles Wilson ` (5 preceding siblings ...) 2009-01-28 16:40 ` Claude Sylvain @ 2009-01-28 17:22 ` Reini Urban 2009-01-28 23:47 ` Kai Raphahn 7 siblings, 0 replies; 22+ messages in thread From: Reini Urban @ 2009-01-28 17:22 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: RFD: cygwin + *native* MinGW compiler 2009-01-28 4:38 Charles Wilson ` (6 preceding siblings ...) 2009-01-28 17:22 ` Reini Urban @ 2009-01-28 23:47 ` Kai Raphahn 7 siblings, 0 replies; 22+ messages in thread From: Kai Raphahn @ 2009-01-28 23:47 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2009-02-11 2:34 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-01-29 9:52 RFD: cygwin + *native* MinGW compiler Danny Smith 2009-01-29 12:29 ` Charles Wilson 2009-01-29 15:13 ` Charles Wilson -- strict thread matches above, loose matches on Subject: below -- 2009-01-28 4:38 Charles Wilson 2009-01-28 5:29 ` Christopher Faylor 2009-01-28 6:14 ` Warren Young 2009-01-28 6:55 ` Greg Chicares 2009-01-28 7:18 ` Charles Wilson 2009-01-28 9:05 ` Yaakov (Cygwin/X) 2009-01-28 11:10 ` Charles Wilson 2009-01-28 11:21 ` Yaakov (Cygwin/X) 2009-01-28 15:19 ` Christopher Faylor 2009-01-28 23:08 ` Greg Chicares 2009-01-29 9:44 ` Charles Wilson 2009-02-11 2:34 ` Greg Chicares 2009-01-28 15:15 ` Ralph Hempel 2009-01-28 15:18 ` Vincent R. 2009-01-28 15:26 ` Christopher Faylor 2009-01-28 16:08 ` Roger Wells 2009-01-28 16:40 ` Claude Sylvain 2009-01-28 17:22 ` Reini Urban 2009-01-28 23:47 ` Kai Raphahn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).