Re: [patch] win32: eliminate wrapper script in main build dir

[Charles Wilson]

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