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'?
> 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.
> > 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
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.