This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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.


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]