From: Keith M. <kei...@us...> - 2006-11-20 21:02:24
|
Corinna Vinschen wrote: >On Nov 20 10:22, Keith MARSHALL wrote: >> I am convinced that the entire autoconf set up for mingw-runtime requires >> a complete overhaul; IMO, Corinna's patch remains broken. It employsan >> unusual distribution of labour between `configure' and `Makefile', and it >> does not correctly utilise the standard `--build' and `--host' flags to >> establish the configuration; instead it improperly, and unnecessarilyIMO, >> adds a `--with-cross-host' flag, without any explanation of its intended >> purpose or usage. > > For the explanation of --with-cross-host see the toplevel configure.in > file. For a MinGW build, using the packages we distribute from SourceForge, the top level configure is in each of two *independent* packages, which are distributed as:-- w32api-m.n[-yyyymmdd-r]-src.tar.gz mingw-runtime-m.n[-yyyymmdd-r]-src.tar.gz (usually as releases, so omitting the embedded snapshot identification) and there is no higher level configure to set up any unconventional voodoo which you might like to see. For our users, everything *must* build cleanly, with just these packages, plus gcc-core, gcc-lang*, binutils, and no more. > As for "adding" a --with-cross-host flag, did you have a look > into winsup/mingw/configure.in as it was before my patch (cvs up -r 1.12 > configure.in && grep with_cross_host configure.in)? I've never looked at it, neither should I need to, since it is *not* a prerequisite for a standalone MinGW build, at least as we implement the build procedure for a linux-x-mingw32 cross, (which is what I am trying to support). > I also think it's > somewhat strange to claim I didn't add any explanation, see > http://sourceware.org/ml/gdb-patches/2006-08/msg00198.html I looked at that, but I don't see any *explanation* of `--with-cross-host'. Furthermore, I don't see any associated `AC_ARG_WITH' or `AC_ARG_ENABLE' in the attached patch set, which IMO is mandatory, when you add an option you expect to be supplied through a `--with-something' or `--enable-something' option; (so it would be `AC_ARG_WITH([cross-host],...)' in this case). > To reiterate, the patch was intended to solve one specific situation > which was not fully covered so far which is, building a fully automated, > self-contained canadian cross with Mingw as host and with the winsup > directory simply being part of a gcc/binutils/gdb/etc source tree. Like > for instance this: > > build = linux, host = mingw, target = arm-elf Well, it may work for you, but it is well and truly broken for me... > which requires to run three builds on the linux machine: > > linux-x-mingw (generate linux->mingw crosstools and mingw libs) ...and I'm only trying to get this far. > linux-x-arm-elf (generate arm-elf libs) > mingw-x-arm-elf (generate mingw->arm-elf crosstools using the > tools and libs built in the 1st step) > If you tried this before my patch, you got stuck due to several tiny > but nevertheless annoying problems outlined in the above mail. After your patch, I get stuck before I've even begun, because configure itself blows up; and the reason it does so? You've added: GCC_NO_EXECUTABLES which implicitly bans all subsequent AC_LINK_IFELSE requests, yet after it you've retained: case "$with_cross_host" in ""|*mingw*|*cygwin*) AC_ALLOCA ;; esac which seems to implicitly invoke it. Also, in `Makefile.in' for `mingw-runtime', I see: ifeq ($(target_alias),$(host_alias)) ifeq ($(build_alias),$(host_alias)) tooldir:=$(exec_prefix) else tooldir:=$(exec_prefix)/$(target_alias) endif else tooldir:=$(exec_prefix)/$(target_alias) endif datadir = @datadir@ infodir = @infodir@ includedir = @includedir@ ifneq (,$(findstring cygwin,$(target_alias))) inst_bindir:=$(tooldir)/bin inst_includedir:=$(tooldir)/include/mingw inst_libdir:=$(tooldir)/lib/mingw inst_docdir:=$(tooldir)/share/doc/mingw-runtime else inst_bindir:=$(bindir) inst_includedir:=$(includedir) inst_libdir:=$(libdir) inst_docdir:=$(prefix)/doc/mingw-runtime endif which frankly, is just obscene; IMO, this sort of logic should already have been properly resolved by `configure', and passed to `Makefile' by AC_SUBST variables. > As for using --with-cross-host instead of "correctly utilis[ing] the > standard `--build' and `--host' flags, you should try a canadian cross > like the above yourself. You will find that even when building with > > build=linux host=linux target=mingw > > as necessary for the first step, Agreed, this is the required setup for building gcc and binutils, but... > this is tweaked to > > build=linux host=mingw target=mingw > > when configuring the target libraries. ...when you come to build the target libraries, you really *are* building them for a `host=mingw32', and you shouldn't need to specify `target' at all; by the time you get there, you are now already cross compiling, using the cross tool chain you just built, for a mingw32 host, and you are done with building the code generators, which need the `target' spec. > That's why --with-cross-host > exists right now and that's why I don't see another solution for this > problem right now. If that's the case, there is something flawed in your build procedure, for I don't have a problem, and I don't need anything beyond the standard `build', `host' and `target' specs, at appropriate phases of the configuration; I do, however, use a master build script to supervise the entire process, and to ensure that the proper configure flags are specified at each phase, (and I don't *ever* specify `with_cross_host', which isn't even referred to in any place within `mingw-runtime' other than in the configure script). FWIW, my master build script is not autoconf generated. However, for an in-tree build such as you describe, I see no reason why the procedure I use could not equally well be implemented through a higher level configure and Makefile setup, *without* requiring the nasty `with-cross-host' kludge you have implemented. > As usual the best arguments are working patches. If you can come up > with a better and more elegant approach which neither breaks Cygwin > builds (native and cross), nor canadian cross builds, fine with me. > But without actual code it's a bit... well, fruitless. And that's precisely why I asked you to contact me. I've no interest in building Cygwin, but I don't want to break it. MinGW *is* broken, at the moment, and I want to fix it. If I can't understand your objectives, (and I can't, without some dialogue), then there is a real danger that I will fix MinGW, but break something for you, and I want to avoid that. Regards, Keith. |
From: Corinna V. <vin...@re...> - 2006-11-21 12:14:53
|
On Nov 20 21:09, Keith Marshall wrote: > Corinna Vinschen wrote: > > For the explanation of --with-cross-host see the toplevel configure.in > > file. > > For a MinGW build, using the packages we distribute from SourceForge, the > top level configure is in each of two *independent* packages, [...] > and there is no higher level configure to set up any unconventional voodoo > which you might like to see. There's no voodoo involved. Even though you rip out the mingw and w32api directories from the sourceware cvs repository they are nevertheless part of it. What I did was trying to fix a flawed process with mingw/w32api still being part of this repository. Maybe I broke the process of doing an uncommon out-of-tree cross build, but this was certainly not intentional. > > As for "adding" a --with-cross-host flag, did you have a look > > into winsup/mingw/configure.in [...] > > I've never looked at it, neither should I need to, since it is *not* a > prerequisite for a standalone MinGW build, at least as we implement the build > procedure for a linux-x-mingw32 cross, (which is what I am trying to support). Well, you adapted a non-standard way of building mingw/w32api as an out-of-tree cross build. If you want to maintain this procedure, go ahead and add a fix. I'm not convinced that this is any better than using the standard environment which is the sourceware source tree. It just means you were going out of your way so as not to have to request and get approval for changes to the toplevel configury. That's certainly your right, but be aware that you are always developing beyond the preception of the developers who are using the standard in-tree approach. > > http://sourceware.org/ml/gdb-patches/2006-08/msg00198.html > > I looked at that, but I don't see any *explanation* of `--with-cross-host'. I explained what happens in the general case. I didn't explain every little detail explicitely. However, from the accompanying ChangeLog and especially the patch it should have been quite clear how the --with-cross-host comes into the picture. > Furthermore, I don't see any associated `AC_ARG_WITH' or `AC_ARG_ENABLE' in > the attached patch set, which IMO is mandatory, when you add an option you > expect to be supplied through a `--with-something' or `--enable-something' > option; (so it would be `AC_ARG_WITH([cross-host],...)' in this case). --with-cross-host is a toplevel configure option which is added automagically to subsequent target library builds. It's not intended as a user changable option. > After your patch, I get stuck before I've even begun, because configure > itself blows up; and the reason it does so? You've added: > > GCC_NO_EXECUTABLES > > which implicitly bans all subsequent AC_LINK_IFELSE requests, yet after > it you've retained: > > case "$with_cross_host" in > ""|*mingw*|*cygwin*) > AC_ALLOCA > ;; > esac > > which seems to implicitly invoke it. GCC_NO_EXECUTABLES allows to disable link tests which are otherwise enabled. So the above case statement just runs the test when $with_cross_host indicates that we're building on a system which supports it, basically. Without GCC_NO_EXECUTABLES, the same statement fails always(*) when running a cross build because the link test is made outside of the scope of the case statement, which is rather an unfortunate feature of autoconf. (*)If this once worked for you, then your build system has apparently an already existing mingw installation it can rely upon. When you build a standalone canadian cross, the compiler already has been built at this point but the MingW libs are still unavailable. Of course, the whole point of building the mingw target directory is creating the libs to be able to link a working binary. Assuming to have already the ability to link at this point in the build process is plainly a wrong assumption. If this breaks for you now, I don't know why. You do. Suggest a fix. OTOH, I don't have the faintest idea what this AC_ALLOCA test is supposed to accomplish. It looks quite useless to me and, assuming I would be interested in overhauling the autoconf stuff, I'd rip it out with GCC_NO_EXECUTABLES altogether. > Also, in `Makefile.in' for `mingw-runtime', I see: > > ifeq ($(target_alias),$(host_alias)) > ifeq ($(build_alias),$(host_alias)) > tooldir:=$(exec_prefix) > else > tooldir:=$(exec_prefix)/$(target_alias) > endif > else > tooldir:=$(exec_prefix)/$(target_alias) > endif > datadir = @datadir@ > infodir = @infodir@ > includedir = @includedir@ > ifneq (,$(findstring cygwin,$(target_alias))) > inst_bindir:=$(tooldir)/bin > inst_includedir:=$(tooldir)/include/mingw > inst_libdir:=$(tooldir)/lib/mingw > inst_docdir:=$(tooldir)/share/doc/mingw-runtime > else > inst_bindir:=$(bindir) > inst_includedir:=$(includedir) > inst_libdir:=$(libdir) > inst_docdir:=$(prefix)/doc/mingw-runtime > endif > > which frankly, is just obscene; As I mentioned previously, I didn't intend to revamp the existing structures. I just added a minimal patch set which allows the canadian cross. If you look into my patch closely you'll find that I just added one "else if" branch for the with_cross_host case to an already existing conditional expression. I didn't question the exisiting expression. > If that's the case, there is something flawed in your build procedure The problem is not the canadian cross procedure, it's the Makefiles (or the configury, whatever you prefer) which didn't know about it. Look at the above expression. It's all about installation paths. Nothing more serious is going on there. > FWIW, my master build script is not autoconf generated. However, for an > in-tree build such as you describe, I see no reason why the procedure I use > could not equally well be implemented through a higher level configure and > Makefile setup, *without* requiring the nasty `with-cross-host' kludge you > have implemented. I didn't implement it, it was already there. I just utilized it for the canadian cross case. > And that's precisely why I asked you to contact me. Sorry, I don't have such a mail in my inbox. Apart from that I don't see the advantage of private discussion here. That's what mailing lists are for. > MinGW *is* broken, at the moment, [...] Your build procedure is broken, not MingW. MingW was broken before my patch. But, oh, maybe that's in the eye of the beholder? > [...] and I want to fix it. I'm just wondering why this has to be discussed at such great length instead of creating a temporary fix which allows this out-of-tree cross build again while maintaining the requirements for an in-tree build. Then you have all the time of the world to come up with a new, revamped autoconf concept. Sarcio non olet ;) Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat |
From: Keith M. <kei...@us...> - 2006-11-25 17:36:03
|
On Tuesday 21 November 2006 12:14, Corinna Vinschen wrote: > On Nov 20 21:09, Keith Marshall wrote: > > Corinna Vinschen wrote: > > > For the explanation of --with-cross-host see the toplevel configure.in > > > file. > > > > For a MinGW build, using the packages we distribute from SourceForge, the > > top level configure is in each of two *independent* packages, [...] > > and there is no higher level configure to set up any unconventional > > voodoo which you might like to see. > > There's no voodoo involved. Really? See below. You yourself later say that `with_cross_host' is defined `automagically'! What's `automagic', if it isn't voodoo? > Even though you rip out the mingw and > w32api directories from the sourceware cvs repository they are > nevertheless part of it. What I did was trying to fix a flawed process > with mingw/w32api still being part of this repository. Maybe I broke the > process of doing an uncommon out-of-tree cross build, but this was > certainly not intentional. > > > > As for "adding" a --with-cross-host flag, did you have a look > > > into winsup/mingw/configure.in [...] > > > > I've never looked at it, neither should I need to, since it is *not* a > > prerequisite for a standalone MinGW build, at least as we implement the > > build procedure for a linux-x-mingw32 cross, (which is what I am trying > > to support). > > Well, you adapted a non-standard way of building mingw/w32api as an > out-of-tree cross build. If you want to maintain this procedure, go > ahead and add a fix. I'm not convinced that this is any better than > using the standard environment which is the sourceware source tree. It > just means you were going out of your way so as not to have to request > and get approval for changes to the toplevel configury. No, it wasn't. I'm simply trying to understand how this stuff is built, in the first place. I want to be able to build just MinGW, *without* having to check out a full Cygwin source tree. I find myself completely baffled by the unconventional hackery I find in there, just to support Cygwin, it seems. And yes, I have now looked in the parent configure setups, all the way back to the CVSROOT, and I'm still none the wiser, for nowhere can I see any explanation of either why, or how `with_cross_host' should be defined; the same applies to another odd-ball: what is `target_os'? Why can these not simply be deduced, as required, from `build', `host', and `target'? > That's > certainly your right, but be aware that you are always developing > beyond the preception of the developers who are using the standard > in-tree approach. But `with_cross_host' and `target_os' aren't defined in any standard manner of which I am aware, and those developers maintaining your so called standard approach appear to have neglected to define what they perceive as `standard'. > > > http://sourceware.org/ml/gdb-patches/2006-08/msg00198.html > > > > I looked at that, but I don't see any *explanation* of > > `--with-cross-host'. > > I explained what happens in the general case. I didn't explain every > little detail explicitely. IMO, you didn't explain anything, intelligibly. > However, from the accompanying ChangeLog > and especially the patch it should have been quite clear how the > --with-cross-host comes into the picture. It isn't. > > Furthermore, I don't see any associated `AC_ARG_WITH' or `AC_ARG_ENABLE' > > in the attached patch set, which IMO is mandatory, when you add an option > > you expect to be supplied through a `--with-something' or > > `--enable-something' option; (so it would be > > `AC_ARG_WITH([cross-host],...)' in this case). > > --with-cross-host is a toplevel configure option which is added > automagically to subsequent target library builds. It's not intended as > a user changable option. And isn't this just another way of saying it is voodoo, that even you probably don't understand, for you seem to be incapable of explaining it? > > After your patch, I get stuck before I've even begun, because configure > > itself blows up; and the reason it does so? You've added: > > > > GCC_NO_EXECUTABLES > > > > which implicitly bans all subsequent AC_LINK_IFELSE requests, yet after > > it you've retained: > > > > case "$with_cross_host" in > > ""|*mingw*|*cygwin*) > > AC_ALLOCA > > ;; > > esac > > > > which seems to implicitly invoke it. > > GCC_NO_EXECUTABLES allows to disable link tests which are otherwise > enabled. No, this is not correct. GCC_NO_EXECUTABLES makes a statement; it says `I intend to use the compiler for compiling object modules only; I will not ask it to link any such modules to create executables'. In making that statement, *you* implicitly promise that you will not specify any linking tests. In return for that promise, GCC_NO_EXECUTABLES arranges things so that you may invoke AC_PROG_CC, AC_PROG_CXX and friends, without testing the ability of the compilers involved to link executables. However, it still expects you to honour your commitment to not specify any linking tests, and it will punish you if you break that promise. > So the above case statement just runs the test when > $with_cross_host indicates that we're building on a system which > supports it, basically. Without GCC_NO_EXECUTABLES, the same statement > fails always(*) when running a cross build because the link test is made > outside of the scope of the case statement, which is rather an > unfortunate feature of autoconf. Eh? This is utter nonsense! `AC_ALLOCA' is there because someone misguidedly specified it. I can't imagine why; it is an expensive test, with the objective of identifying how the runtime library provides support for C's `alloca' function. Since we are providing the implementation, we should know that anyway, so why do we need to test for it in the first place? Secondly, since the runtime library doesn't even exist, when we run this test, then the expected and unequivocal result must be that the non-existent library obviously does not provide any mechanism for supporting `alloca', at all. What is unfortunate, is that you wrapped the original unconditional AC_ALLOCA request in a case statement, the controlling conditions of which are not clearly understood, obfuscating an original error, but retaining it in any fashion remains an error. Never mind; I've now corrected that. > (*)If this once worked for you, then your build system has apparently an > already existing mingw installation it can rely upon. When you build a > standalone canadian cross, the compiler already has been built at this > point but the MingW libs are still unavailable. Of course, the whole > point of building the mingw target directory is creating the libs to be > able to link a working binary. > Assuming to have already the ability to link at this point in the build > process is plainly a wrong assumption. > > If this breaks for you now, I don't know why. You do. Suggest a fix. > OTOH, I don't have the faintest idea what this AC_ALLOCA test is > supposed to accomplish. It looks quite useless to me ... and to me. Rather that forlornly try to bypass it, as you did, I've removed it altogether; there can be no possible justification for keeping it. > and, assuming I > would be interested in overhauling the autoconf stuff, I'd rip it out > with GCC_NO_EXECUTABLES altogether. > > > Also, in `Makefile.in' for `mingw-runtime', I see: > > > > ifeq ($(target_alias),$(host_alias)) > > ifeq ($(build_alias),$(host_alias)) > > tooldir:=$(exec_prefix) > > else > > tooldir:=$(exec_prefix)/$(target_alias) > > endif > > else > > tooldir:=$(exec_prefix)/$(target_alias) > > endif > > datadir = @datadir@ > > infodir = @infodir@ > > includedir = @includedir@ > > ifneq (,$(findstring cygwin,$(target_alias))) > > inst_bindir:=$(tooldir)/bin > > inst_includedir:=$(tooldir)/include/mingw > > inst_libdir:=$(tooldir)/lib/mingw > > inst_docdir:=$(tooldir)/share/doc/mingw-runtime > > else > > inst_bindir:=$(bindir) > > inst_includedir:=$(includedir) > > inst_libdir:=$(libdir) > > inst_docdir:=$(prefix)/doc/mingw-runtime > > endif > > > > which frankly, is just obscene; > > As I mentioned previously, I didn't intend to revamp the existing > structures. I just added a minimal patch set which allows the canadian > cross. If you look into my patch closely you'll find that I just added > one "else if" branch for the with_cross_host case to an already existing > conditional expression. I didn't question the exisiting expression. > > > If that's the case, there is something flawed in your build procedure > > The problem is not the canadian cross procedure, it's the Makefiles (or > the configury, whatever you prefer) which didn't know about it. Look at > the above expression. It's all about installation paths. Nothing more > serious is going on there. Be that as it may, this is still a complete mess. The installation paths should be completely specified by `bindir', `libdir', `includedir', `docdir', etc., all of which propagate in a standard, and fully documented fashion, from any autoconf generated configure script. Why do we need this extra layer of undocumented complexity? > > MinGW *is* broken, at the moment, [...] > > Your build procedure is broken, not MingW. MingW was broken before my > patch. But, oh, maybe that's in the eye of the beholder? Well, any sane beholder must acknowledge that it *was* broken! The AC_ALLOCA test *guaranteed* that, and your addition of GCC_NO_EXECUTABLES compounded that breakage, by forcing configure to abort, when it reached that test, in a *normal* build situation. > > [...] and I want to fix it. Ok. I've gone ahead and removed the AC_ALLOCA fault. I've also corrected the improper quoting of autoconf macro arguments, and removed several redundant AC_SUBSTs, but I'd still like to tidy this stuff up some more; while it should now work, IMO it remains a maintenance nightmare. > I'm just wondering why this has to be discussed at such great length... It wouldn't need to be, if you would simply answer my original question: `What is your objective in specifying the unconventional `with_cross_host', (and I will now add `target_os')? Why can the required features not be properly supported using the standard `build', `host' and `target' specifications?' If you will not, or cannot answer that, then I have to try to deduce your intentions from the ill documented mess that I find in the code; I really don't feel comfortable working on software, when I don't properly understand what it is trying to achieve. Regards, Keith. |
From: Christopher F. <me...@cg...> - 2006-11-25 18:21:40
|
On Sat, Nov 25, 2006 at 05:43:05PM +0000, Keith Marshall wrote: >IMO, you didn't explain anything, intelligibly. >Eh? This is utter nonsense! > >and to me. Rather that forlornly try to bypass it, as you did,... > >> I'm just wondering why this has to be discussed at such great length... > >It wouldn't need to be, if you would simply answer my original question: `What >is your objective in specifying the unconventional `with_cross_host', (and I >will now add `target_os')? Why can the required features not be properly >supported using the standard `build', `host' and `target' specifications?' >If you will not, or cannot answer that, then I have to try to deduce your >intentions from the ill documented mess that I find in the code; I really >don't feel comfortable working on software, when I don't properly understand >what it is trying to achieve. If you really want to accomplish something here, then perhaps the best course of action would be to eschew the inflammatory comments and just focus on providing a patch which cleans up the problems that you perceive and does not perturb the usage that Corinna (and others) need. cgf |
From: Keith M. <kei...@us...> - 2006-11-25 20:05:09
|
On Saturday 25 November 2006 18:14, Christopher Faylor wrote: > If you really want to accomplish something here, then perhaps the best > course of action would be to eschew the inflammatory comments and just > focus on providing a patch which cleans up the problems that you perceive > and does not perturb the usage that Corinna (and others) need. That's exactly what I would like to do. However, I should be grateful if you, or Corinna would actually *explain* what it is that she, and others do need, for I'm finding it extremely difficult to extract that information, or even a pointer to where it might be documented, from either of you. |
From: Christopher F. <me...@cg...> - 2006-11-26 06:09:33
|
On Sat, Nov 25, 2006 at 08:12:20PM +0000, Keith Marshall wrote: >On Saturday 25 November 2006 18:14, Christopher Faylor wrote: >>If you really want to accomplish something here, then perhaps the best >>course of action would be to eschew the inflammatory comments and just >>focus on providing a patch which cleans up the problems that you >>perceive and does not perturb the usage that Corinna (and others) need. > >That's exactly what I would like to do. However, I should be grateful >if you, or Corinna would actually *explain* what it is that she, and >others do need, for I'm finding it extremely difficult to extract that >information, or even a pointer to where it might be documented, from >either of you. I suspect that it is just a simple: configure --target=i686-mingw32 --host=i686-linux --build=i686-linux and possibly configure --target=powerpc-linux --host=i686-mingw32 --build=i686-linux from the directory above winsup. cgf |
From: Corinna V. <vin...@re...> - 2006-11-27 09:11:03
|
On Nov 25 17:43, Keith Marshall wrote: > I want to be able to build just MinGW, *without* having to > check out a full Cygwin source tree. If you don't want to check out Cygwin, ask the sourceware overseers to create a mingw CVS module entry. It's that easy. > I find myself completely baffled by the > unconventional hackery I find in there, just to support Cygwin, it seems. > And yes, I have now looked in the parent configure setups, all the way back > to the CVSROOT, and I'm still none the wiser, for nowhere can I see any > explanation of either why, or how `with_cross_host' should be defined; I tried to explained that in my first reply. When you build build=A host=A target=B then the target libraries are built with build=A host=B target=B which means, the Makefiles in the target libraries don't know anymore, whether the target libs are installed on the build machine or on the host machine. with_cross_host OTOH is still set to A which allows to recognize that the "real" host will not be B, but A. > the same applies to another odd-ball: what is `target_os'? Why can these not > simply be deduced, as required, from `build', `host', and `target'? info autoconf Other than that, you're barking the wrong tree. I did neither invent autoconf, nor the configury on sourceware. I just use it. EOD, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat |
From: Keith M. <kei...@us...> - 2006-11-30 04:47:32
|
On Monday 27 November 2006 09:10, Corinna Vinschen wrote: > On Nov 25 17:43, Keith Marshall wrote: > > I want to be able to build just MinGW, *without* having to > > check out a full Cygwin source tree. > > If you don't want to check out Cygwin, ask the sourceware overseers to > create a mingw CVS module entry. It's that easy. No need for that. I don't have the slightest problem checking out the components I need, without any change, and without needing a full Cygwin checkout. > > I find myself completely baffled by the > > unconventional hackery I find in there, just to support Cygwin, it seems. > > And yes, I have now looked in the parent configure setups, all the way > > back to the CVSROOT, and I'm still none the wiser, for nowhere can I see > > any explanation of either why, or how `with_cross_host' should be > > defined; > > I tried to explained that in my first reply. When you build > > build=A host=A target=B > > then the target libraries are built with > > build=A host=B target=B It wasn't this that I had an issue with. I *fully* understand the build/host/target paradigm, whether it relates to native, simple cross, canadian, or crossback builds; and I also fully understand why the runtime libs for the target *must* be built with *host* set to match the *compiler's* target. > which means, the Makefiles in the target libraries don't know anymore, > whether the target libs are installed on the build machine or on the > host machine. Huh? Regardless of where you build the beast, the libs *must* ultimately be installed on the host which will eventually run the compiler you just built; otherwise that compiler will never be able to create executables. > with_cross_host OTOH is still set to A which allows > to recognize that the "real" host will not be B, but A. Thanks. This was the piece of the jigsaw I was missing. I need to think about this some more; at the moment I'm not convinced that it is needed, but I might change that opinion, when I get my head around it a bit better. > > the same applies to another odd-ball: what is `target_os'? Why can these > > not simply be deduced, as required, from `build', `host', and `target'? > > info autoconf Thanks for this, too. I've read that countless times, but I've always overlooked, or rather failed to take note of, this particular detail. > Other than that, you're barking the wrong tree. I did neither invent > autoconf, nor the configury on sourceware. I just use it. Well, it was *your* use of it that was puzzling me; who else would I ask for clarification of that? > EOD, > Corinna I unreservedly apologise for the inflammatory tone of my earlier post; it was prompted by frustration at not getting a straight answer to what I perceived to be a simple question, but I should not have allowed that to colour my reply. I would, however, suggest that unilaterally declaring EOD is not the best way to engender a spirit of bridge building. Thanks anyway, for finally putting me straight on the `with_cross_host' issue. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-11-30 14:30:55
|
Quoting Keith Marshall <kei...@us...>: >> >> I tried to explained that in my first reply. When you build >> >> build=A host=A target=B >> >> then the target libraries are built with >> >> build=A host=B target=B > > It wasn't this that I had an issue with. I *fully* understand the > build/host/target paradigm, whether it relates to native, simple cross, > canadian, or crossback builds; and I also fully understand why the runtime > libs for the target *must* be built with *host* set to match the *compiler's* > target. > In relation to cygwin's include directory the mingw and w32api headers install into include/mingw and include/w32api. This causes extra logic to be needed to make that happen but only if the target is cygwin. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. -- ****************************************************************************** * The user of this server has agreed to allow the use of a trailer in the * * mail that he sends for advertising purposes. This advertisment is added * * by the server and is not in the control of the user of our services. * ****************************************************************************** Save on your shoes, socks and other needs: http://give-me-an-offer.com/store/shoes Save on your baby gift needs: http://give-me-an-offer.com/offers/products/baby |