[avail for test] libtool-devel-20030121-1

[Charles Wilson]

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/