This is the mail archive of the
mailing list for the Cygwin project.
RE: [avail for test] libtool-devel-20030121-1
- From: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>
- To: "Charles Wilson" <cwilson at ece dot gatech dot edu>,<cygwin at cygwin dot com>
- Date: Mon, 3 Feb 2003 21:02:55 +0100
- Subject: RE: [avail for test] libtool-devel-20030121-1
> 3) What I did: create a binary wrapper -- an actual executable --
> named 'foo.exe' in the main build directory. It is NOT the real
> foo.exe. It simply exec's the shell script, which in turn sets up the
> environment and exec's the real .lib/foo.exe. Eventually, the 'set up
> the environment' part could be moved into the binary wrapper itself, at
> least on cygwin/mingw -- but there are problems with that; libtool
> itself *sources* and parses the shell wrapper -- it can't do that with a
> binary wrapper. So that's for later. This works now, even if it is a
> bit kludgey.
> Unfortunately, it might lead to a FAQ: the shell wrapper contains a
> banner at the top that says "This is not the real foo.exe. It is a
> wrapper" blah blah blah. Plus, it's named 'foo' instead of 'foo.exe' --
> a tipoff for us windows denizens. Now, you have:
> <builddir>/foo : shell wrapper
> <builddir>/foo.exe : binary wrapper
> <builddir>/.lib/foo.exe : the real executable
i've played a little with this stuff and have seen, that at least for cygwin
there is an easier way to deal with this. Create a simple link from 'foo' to
'foo.exe' and Makes need are fullfilled.
# The program doesn't exist.
\$echo \"\$0: error: \$progdir/\$program does not exist\" 1>&2
\$echo \"This script is just a wrapper for \$program.\" 1>&2
echo \"See the $PACKAGE documentation for more information.\" 1>&2
chmod +x $output
+ ln -s $output $output$exeext
The single added line fix this.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html