no gifs due to patent problems
Inter-library Dependencies have been re-enabled, starting from
libtool-1.2c by merging an old patch from Toshio Kuratomi into the current
tree. It all seems to be working, but needs to be ported to more
architectures. Currently, we have support for:
If you don't care about the history, and you just want to help out by porting inter-library dependencies to another platform, check out the latest cvs version of libtool and send your patches to the list.
We think we have solved most of the problem described below. If you know different, please make sure you are running the latest release, and tell us exactly what you did to break it.
We have some suspicions about the robustness of some of the ports listed above, namely those that use pass_all as the value for deplibs_check_method. Read the sources for more detail.
Libtool's basic premise is to make static and shared libraries behave the same way from a programmer's point of view. This allows users to build a libtoolized package with or without shared libraries, determined at configuration time. It does this by using a libtool object (.lo) and libtool archive (.la) abstraction, so that the package maintainer can use libtool to operate on these files without making any assumptions about their underlying representation.
For the most part, this abstraction works well, and has made libtool as popular as it is today. Without this abstraction, it would be significantly harder to port libtool to new platforms.
Unfortunately, what this abstraction has also done is reveal some fundamental inconsistencies with most shared library implementations. Every shared library implementation works well for `hello world'-type examples, but very few are robust and well-designed so that libtool doesn't need special tricks in order to build correct, featureful shared libraries.
Providing inter-library dependencies is one feature that has revealed these kinds of inconsistencies.
My orginal inter-library dependency code received rigourous testing in beta releases of GNU Guile. As soon as the Guile people started using my code, I received a flood of bug reports. People were reporting that libguile (Guile's main shared library) was failing to link, or that programs linked against libguile were dumping core.
The Guile people chased this bug down to the following scenario:
I needed some way to respond to these reports. I saw my options (in order of my preference) as:
I immediately vetoed the last solution, because that would violate the whole point of using libtool, and would cause a lot of people to waste time solving a problem that really should be fixed by libtool.
I preferred the first solution, but at the time of the reports, I didn't see an obviously simple mechanism for detecting the difference between shared and static libraries.
So, in the meantime, I tried turning off inter-library dependencies on the systems that failed.
I quickly discovered, to my chagrin, that many systems fail. So, it was be simpler for me to turn off all inter-library dependencies, then find out which systems work, rather than vice versa.
I've been busy trying to avoid bankruptcy. It's been over three months since I first turned off inter-library dependencies, and I still haven't completed the solution I want.
I've been gearing up for the 1.1 release of libtool, because there is a high demand for a stable public release. So, I'm not going to introduce any destabilizing changes to the inter-library dependency code until after 1.1 is released.
So, I want to tell you how you can help me solve the various dilemmas surrounding this issue:
Thank you for your help, and have fun.
Back to the libtool home page.