Ralf Wildenhues wrote:
* Charles Wilson wrote on Sun, Jun 17, 2007 at 02:43:02AM CEST:
Now, in this current patch, we only use _spawnv() if $host == mingw.
Maybe we could be more clever than that, and only use _spawnv if mingw
and native. However, we'd then need to do something about this:
# we should really use a build-platform specific compiler
# here, but OTOH, the wrappers (shell script and this C one)
# are only useful if you want to execute the "real" binary.
# Since the "real" binary is built for $host, then this
# wrapper might as well be built for $host, too.
$opt_dry_run || $LTCC $LTCFLAGS -s -o $cwrapper $cwrappersource
Ah, yes. Good, looks like your patch doesn't make things worse here.
OK; I'll ignore this issue for now.
The new suite fails tests 25 26 32 54 now, which it
didn't back on 2007-02-24, which is when I last tested it.
I got those failures (native), until I fixed tests/destdir.at to include
$EXEEXT on $bindir/m:
[...]
Perhaps that "fix" breaks cross?
No, the failure is earlier: the install command does not find the
programs. I can "fix" them (make them skip again) by means of the patch
below. OK?
OK by me. Do you wat me to add your patch to mine and check it all in
at once (e.g. keep the new-testsuite .exe fixes to destdir.at together),
or will you check your changes in separately?
(Seeing that we need this change, I wonder how many
packages not using Automake (and how many even using Automake) will
break by the new semantics of not having 'prog' but only 'prog.exe'
at least in the cross-compile case...)
Probably a fair many. However, IMO those packages were improperly
ported to support (cross-) compiling for mingw anyway: they were relying
on an internal implementation detail of libtool, in that it happened to
create a wrapper script with the same full name as the executable
created by the compiler on 'regular' *nix.
Grepping the verbose output of the old HEAD testsuite for 'No such file
or directory' shows several bits that need adjustment, too.
Well, this is a bit more excusable: INSIDE libtool, we're allowed to
depend on internal libtool details. Even if it isn't a really good
idea, as in this case.
Notwithstanding the answer to my question above concerning
new-testsuite/destdir.at, I'd appreciate it if you would (at least)
provide me with your cross-compile verbose log from the old testsuite,
or (at best) a followup patch to fix these issues -- since I don't have
a cross-compile setup, here.
In any case, I'd like to postpone the cross-compile old-testsuite .exe
fixes to a followup patch.
I could use some advice on the following: trying to add a new magic
string to the executable, I did the obvious (shown after variable
replacement, etc:
static const char *MAGIC_EXE = "%%%MAGIC EXE variable%%%";
But the compiler stripped the symbol and the initialization string out
of the executable.
For now just drop the static. This will work until LTO (link time
optimization) is deployed. Not sure what we'll need with that in place,
but I suppose either make the variable volatile (another non-fix) or add
a stub volatile access to it in main.
OK. I've already tested that and it does work -- at least at present.
I'll post my current patch in a little while, although I still need to
test it on (native) mingw, and linux.
--
Chuck
