Hallo Ralf, Bob, Peter, Eric,
Is this patch really necessary for 2.0? I think that introducing so
much code churn in to libtool at this stage is going to bring yet more
release delays. Surely the feature is useful and desireable, but I
really *really* want to avoid more delays for 2.0.
Now is the time to branch! Either a feature branch for developing the
per-deplib feature for merging after 2.0, or else a 2.0 branch that we
can keep stable.
My preference is to make a feature branch now, and not branch for 2.0
at least until the release blockers are resolved, so that we can commit
any bugfixes we discover during testing just once (we went through the
mess of porting to three branches during the last branch-2-0 debacle,
and I don't want to do that again!).
According to: http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap, the
three remaining release blockers for 2.0 are:
* ! libtool.m4 macro ordering/requirement audit. pending
* ! LT_WITH_LTDL should build libltdl by default; currently
nothing happens unless LTDL_CONVENIENCE or LTDL_INSTALLABLE
is also given.
* ! fix potential denial of service with compilers that do not
understand -c -o.
* not very likely to happen
* http://lists.gnu.org/archive/html/libtool-patches/2005-03/msg00252.html
And I would even dispute whether the first of those is really a release
blocker -- the code *does* need an audit, but it's been in that state for
several existing releases already. lists.gnu.org and mail.gnu.org appear
to be down, so I can't read the post attached to the final blocker to
remind myself of that issue.
So here are the action points, initialed where I plan to take them
pending agreement from (most of) you guys.
1. strike the macro ordering audit from the release blocker list. GVV
2. fix LTDL_{CONVENIENCE,INSTALLABLE} bug on CVS HEAD. GVV
3. make a per-deblib-branch for these changes.
4. evaluate whether -c -o DoS is a release blocker too.
4a. fix it if it is
4b. strike it from the blocker list if it isn't
5. test like crazy. and fix any platform issues uncovered GVV
6. release libtool-2.0 already! GVV
Once 2.0 is finally out, I will take a back seat with libtool for a while
to work on m4-2.0 and my new book.
Ralf Wildenhues wrote:
Hi Bob, Albert,
* Bob Friesenhahn wrote on Wed, Feb 01, 2006 at 07:47:51AM CET:
On Tue, 31 Jan 2006, Albert Chin wrote:
On Mon, Jan 30, 2006 at 10:28:52PM +0100, Ralf Wildenhues wrote:
- Should the corresponding libtool flags be named `-Bstatic' resp.
`-Bdynamic'? Those were the most common names I could find, but IMHO
they are not very self-explanatory for users not used to them.
-prefer-static, -prefer-dynamic/-prefer-shared? The -Bxxx doesn't seem
similar with current libtool options.
At least for the static case, I would prefer the link to entirely fail
if a static library is requested but one can not be found. Usually
there is a very important reason to use a static library if it has
specifically been requested. So the wording should not be 'prefer'
for the static case. I agree that the -B syntax does not fit the
style of other libtool options (but does match many linkers).
Several different issues here:
- the option naming, which I will not delve into in this post, and
- whether what I'll call -Bstatic for now should fail if it does not
find a static library to link against.
The latter point is intricate, and requires much more elaboration to be
completely specified. That's the main reason I kept the semantics so
vague in my proposal. The issues are: library search algorithm,
difference between libtool and non-libtool libraries, linker capability.
1) The linker may not allow to specify per-deplib linkage at all, or may
not have a flag to force static linkage (as opposed to only _prefer_ it).
Examples for the former are Darwin; I haven't found an example for the
latter yet (good!). But this means, that for non-libtool libraries we
cannot guarantee a certain linking mode, unless we were to change our
search algorithm quite drastically (which I don't see as an option ATM).
2) Difference between libtool libraries (*.la) and non-libtool ones, and
libtool search algorithm and native linker search algorithm.
The current libtool library search algorithm looks a bit like this
(before my patch):
- given `path/to/libfoo.la', that is taken and nothing else.
- given `path/to/libfoo.a' ($libext), that is taken and nothing else.
- given `-lfoo'
for all searchdirs that we look at,
for the extensions `.la', `$std_shrext', `.so', `.a' [1]
check whether there exists a file libfoo.$extension
if yes, exit search algorithm
My patch skips `$std_shrext' and `.so' when in Bstatic mode, but it
still happily picks the first `.la' file it can find, even iff that one
was shared-only, for example. Currently it then links shared
