Mail Archives: cygwin/2003/02/02/16:21:06
I've updated libtool-devel to the 20030121 CVS, plus added a major
change of my own (inspired by Earnie Boyd and others on the libtool
mailing list) that "fixes" the 'relink exe's over and over and over'
problem on both mingw and cygwin.
[Skip to the last two paragraphs for the real important part]
A (not-so-short) description of the problem and the solution approach
taken: if you have a package that builds a shared library (.dll) AND an
exe which relies on that library, then libtool puts the actual
executable into a .lib/ subdirectory under your current build directory,
and NOT in the build directory itself.
This is also done on "real" unix platforms. The reason is that
uninstalled shared libraries cannot easily be found by the runtime
loader on most platforms, unix and cygwin/windows included.
So, in order to run the uninstalled executable, you must first set the
environment appropriately so that the shared library (.dll) will be
found. This means setting LD_LIBRARY_PATH on some unices, or setting
PATH on cygwin so that the Windows Runtime Loader will find the .dll.
libtool does this by creating a shell script in the actual build
directory. The shell script sets the variables and then exec's
./lib/my-real-executable.
If your application is "foo", this works fine on unix. The makefile
wants to see 'foo' -- and it does; only the 'foo' that make sees is
actually a shell script:
<builddir>/foo : a shell script
<builddir>/.lib/foo : the real executable
And it only gets built once. However, on cygwin/windows, you have
<builddir>/foo : a shell script
<builddir>/.lib/foo.exe : the real executable
and the makefile *wants* 'foo.exe' -- but only sees 'foo'. Therefore,
make assumes that the executable hasn't been created, and builds it
again. EVERY time you run 'make <anything>'. Sometimes *multiple*
times if there are cross-dependencies.
There were several solutions:
1) Teach 'make' to only want 'foo' instead of 'foo.exe'. There are
problems here -- this requires mucking with automake, which has the
potential to break non-libtool builds if not done carefully.
2) Name the script 'foo.exe' -- bad idea. cygwin and mingw take one
look at the extension, and simply exec it directly *without* parsing the
first line for an interpreter. Doing this would actually require mods
to the cygwin and MSYS kernel -- and would slow cygwin down on *every*
executable invokation.
<note: the following is true only for cygwin/mingw builds>
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
There's no easy way to 'label' <builddir>/foo.exe as a wrapper -- so
some folks may be tempted to install it, with disappointing results.
Perhaps if the binary wrapper doesn't find .libs/foo.exe, it can report
an error of the form:
"You must have installed foo.exe by hand, because I am not the
real foo.exe. I am simply a wrapper used during the build process. Go
back to your build directory, and look in the .lib subdirectory for the
real foo.exe. And next time, use 'make install' -- don't try to install
libtoolized packages by hand."
In any case, my patch has made it into libtool CVS as of 2003-01-30
(without the friendly error message), but I haven't updated this test
distribution to that level; I'm simply releasing my patched version of
2002-01-21.
So, test and enjoy; I will probably make this the official cygwin
libtool-devel very soon. It has been up on my off-site cygutils testing
area for almost two weeks, and now that Robert Boehne has put this
iteration of my patch into CVS I wanted to release it to a wider testing
audience.
Unless there are significant bugs reported, I do not expect to update
our libtool-devel again until libtool-1.5 is released, which may be in a
month -- or it may be in June. For now, I am happy with the status of
libtool-devel (the friendly error message is just a simple cosmetic fix;
I'm too swamped right now to worry about cosmetics; functionality only.)
[IMPORTANT]
Translation: this will be the basic behavior of official libtool-1.5 on
cygwin. If you don't like it, now is the time to yell. So TEST, you
huskies, TEST!
Anyway, you know the drill: setup.exe, choose 'Experimental', etc.
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -