[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool 2.2.2 cross-compile to mingw problems

From: Charles Wilson
Subject: Re: libtool 2.2.2 cross-compile to mingw problems
Date: Wed, 23 Apr 2008 19:31:11 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20080213 Thunderbird/ Mnenhy/

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 ;;
    * ) do nothing

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".

  CYGWIN=" stuff but not transparent_exe "

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]