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 |