Re: libtool 2.2.2 cross-compile to mingw problems

[Charles Wilson]

Roumen Petrov wrote:
> Ok it seems to me reasonable to dropout old behaviour to avoid problem 
> with "transparent_exe" option on build platform.
> Is possible during configure time to detect whether "transparent_exe" 
> option is switched "on" ?

But it's not just that. The old libtool was completely broken if 
CYGWIN=transparent_exe, but there were still other problems, on both 
native cygwin and native msys, with coreutils and foo.exe+foo in the 
same directory -- even if !transparent_exe.  There were several patches 
over the years trying to address the issue with various heuristics: 
check for 'foo.' to suppress auto-.exe-extension, which worked for a 
while...  It's just a bad idea, on win32, to have foo and 
foo.[bat|exe|com|...] in the same directory.

>> However, the presence of both foo and foo.exe in the same directory
>> causes some problems with coreutils/shells' "autodetect .exe's" logic
>> under "native" MSYS and "native" Cygwin.  And it's downright unusable
>> when the cygwin "transparent_exe" option is active.

> Other question is presence of any wrapper scripts. I include my test 
> case (see attached file bootstrap.sh.gz).
> The make create: test.exe .libs/test_ltshwrapper .libs/test.exe and etc 
> (not important
> to report).
> The test.exe create .libs/test_ltshwrapperTMP .

Correct. The two versions of the wrapper are used for different purposes 
-- and currently, this odd arrangement is employed only if $host is 
cygwin or mingw.   The one created by make is never supposed to be 
executed -- it is only ever 'sourced' back into libtool.  The *TMP one 
is just that -- temporary.  The wrapper exe creates it on the fly EVERY 
time it is run, and then exec's it.

> The script .libs/test_ltshwrapper seems to me useless due errors:
> ================
> $ sh .libs/test_ltshwrapper
> .libs/test_ltshwrapper: error: `..../.libs/.libs/test.exe' does not exist
> This script is just a wrapper for test.exe.
> See the libtool documentation for more information.
> ================

That's because it is not supposed to be executed.  It is generated, as 
you noticed, by the same libtool.m4sh function that OTHER platforms use 
to create a shell wrapper in *the actual build dir*.  Therefore, it sets 
WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=no -- just like they do.  However, this 
copy, in our case, IS in .libs (e.g. OBJDIR), so of course it's "broken".

I didn't feel like uglifying the code, just so that a wrapper script -- 
which we *never* intend to execute, only to read -- *could* be executed 
by somebody else.

> Why this script(.libs/test_ltshwrapper) is created by make (...libtool 
> --tag=CC --mode=link ...) ?
> Why is not created with WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=yes and 
> test.exe just to run it?

see above.

> If is possible to detect platform with "transparent_exe" 

But as I said, there are *other* problems as well.  Furthermore, I don't 
think either the cygwin people or the libtool people want this ugliness:

  case "$host" in
    *cygwin* )
      case "$CYGWIN" in
        *transparent_exe* ) set_some_flag ;;
        * ) unset_some_flag ;;
      esac
      ;;
    * ) do nothing
  esac

Not only is that horrible code, but also the value of CYGWIN is an 
internal cygwin implementation detail. The name might change tomorrow. 
Or the default might become transparent_exe and the option name switched 
to visible_exe.

Then, what's libtool supposed to do with some_flag? If set, behave in a 
completely different manner, so we have two different codepaths for the 
same $host, depending on the value of an environment variable that some 
user might change?

What if I have CYGWIN=transparent_exe today, and do a configure/build -- 
and then log off.  Tomorrow, I remove that setting...and my build 
directory is broken so that I can't run the tests.

(It's even worse; new values of $CYGWIN are only recognized when the 
cygwin1.dll is first (re-)loaded into memory.  So, you have to shut down 
all running cygwin processes before changing it.  Consider: I have 
running cygwin processes, who all know that CYGWIN=transparent_exe.  In 
a bash script, I decide to "turn that off" so "libtool will work".

  #!/bin/sh
  CYGWIN=" stuff but not transparent_exe "
  ./configure
  make

The ugly libtool code that checks $CYGWIN thinks "no transparent_exe" 
but in reality, the DLL was never reloaded. So the actual behavior is 
still "transparent_exe".  Boom.

And that's just transparent_exe.  There were *other* issues with the old 
setup as well.

> why libtool do 
> not create (on other build platforms) wrapper scrip as before ? In this 
> case test.exe can try to run it directly without to create 
> .libs/<PROGRAM>_ltshwrapperTMP.

This is not going to change, for native builds. It was *always* a really 
*bad* idea, back in 1.5.0pre, to have both foo.exe and foo in the same 
directory. On build platforms like win32 that allow 
exec()/system()/CreateProcess()/what-have-you, when called with the 
argument "foo", to succeed when only the file "foo.exe" exists.

However, we *can* detect that we're cross-compiling. And wrappers are 
only intended for use by someone with access to the build directory and 
build platform...so, maybe we should use $build instead of $host to 
determine whether needs_c_wrapper?

Any thoughts on that, Ralf, Peter?

> Also I'm familiar with other disadvantage of old behaviour: the path set 
> by wrapper script is overwritten by wine. To overcome this limitation, 
> when project create libraries in different paths, I add a specific 
> directory the the wine path and before to run tests I purge it and 
> populate project libraries into it. But for some projects this is not 
> issue.

I'm not familiar enough with wine to comment on this.

--
Chuck