Re: libtool-2.0 release

[Ralf Wildenhues]

Hi Gary,

Gary V. Vaughan writes:
>
> Is this patch really necessary for 2.0?

No.

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

OK.

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

No way, without me.  I outright refuse to maintain another branch.
It's insane.  It makes more work for us and causes the resulting code
to receive less outside testers per branch.

However, I have absolutely no problem with delaying the application of
the per-deplibs-flags patch to shortly after 2.0.0 or 2.0.2.  Although
we should still commit both the `-static' hardcoding fix and the
static.at test patch (the latter is written so that it works also
without the per-deplibs-flags patch; it needs only -static-libtool-libs).

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

Right.  So we put this off, and don't apply it anywhere right now.

> According to: http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap, the
> three remaining release blockers for 2.0 are:

The list is outdated.

>  * <!> libtool.m4 macro ordering/requirement audit. pending

This is as good as done.  Forget about it.  I have a list of remaining
issues (not with me right now), and I will get to it eventually, but am
pretty sure those issues are not important to many users.

>  * <!> LT_WITH_LTDL should build libltdl by default; currently
>        nothing happens unless LTDL_CONVENIENCE or LTDL_INSTALLABLE
>        is also given.

I don't even know what this means.  I'd guess we should ignore it?

>  * <!> fix potential denial of service with compilers that do not
>        understand "-c -o".
>        * not very likely to happen

I don't mind postponing that to after 2.0, iff that is _not_ responsible
for bugs like this one: http://bugs.debian.org/350989 .  I have replied
there, BTW.


HOWEVER.

- The regressions that happened in 1.5.22 need to be fixed in 2.0, IMHO
  (most notably the OpenBSD failure; and good would be the
  application of the `-static-libtool-libs' patch for users that
  need the other `-static' semantics; together with the hardlinking
  regression that I also found for `-static').
- And my outstanding patch-6 needs to be split up and applied.
  It fixes most but not all remaining issues with HEAD libtoolize.
- I know about a couple more tweaks necessary for HEAD libtoolize
  and Bob has a couple of failures I (or somebody else) need to track
  down.
- AC_PROG_SED may not be AC_DEFUNed (for aclocal < 1.6?), and
  LT_AC_PROG_SED should be catered for.
- Makefile.am rules somewhere use GNU make 3.80 features.  I have
  encountered many difficulties preventing autotools reruns on other
  systems, and am quite fed up with hunting these down.
- I have a pending Solaris/whole_archive_flag_spec patch, fixing a
  regression, and to make libtool work on Solaris 10.

> 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

OK.  Whatever that may be.  You webpage does not seem accessible at the
moment.

>  3. make a per-deblib-branch for these changes.

Do not make a branch.  Pretty please.

>  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

See above.  I have a half-baked fix lying around somewhere, but will
post only after many tests.

>  5. test like crazy. and fix any platform issues uncovered           GVV

If I haven't made it clear yet: that is what I've *really* been doing.
The static test was the aim, and the bulk of the work, the per-deplibs
flags and the `-static' hardcoding fix were the fallout.

And I have several more tests which I would like to write or have
already started.  For example: I would like comprehensive exposure of -L
path issues in order to fix the OpenBSD link `-L path order issue' right,
so that it does not turn into another regression on another system.

I know you would rather release.  There is a trade off: better test
exposure vs. release delay.  My being fed up with working on bootstrap
and similar issues that were mostly introduced by the great code
reorganizations, and also there being very few test suite contributors
and people working on bug reports, has led me to work on the former.

Libtool will only get consistently better with a testsuite that exposes
much more issues.  And if you then keep to adding features only with
comprehensive test exposure already (which static.at probably isn't for
the patch at stake here), then adding features to libtool won't
destabilize it much.

Cheers,
Ralf