Re: [PATCH v2 0/3] sysroot followup patches

[Ralf Wildenhues]

Hi Charles, Paolo,

* Charles Wilson wrote on Mon, Aug 16, 2010 at 05:12:03PM CEST:
> On 8/12/2010 9:23 PM, Paolo Bonzini wrote:
> > These cover bullets 3/5 of Charles' list:
> > 
> > 3) issue with '# Collect and forward deplibs of preopened libtool libs'
> >    In progress? Anything?
> > 4,5)
> >    * patch for old libtool, to not barf on '='
> >    * TBD mechanism to strip '=' from .la after deployment on $host
> > 6) support in libltdl for '=' in .la files
> > 
> > I didn't do 4...
> 
> Well, sure. We really need to discuss how to approach this. It's not
> like we want to cut a new release of libtool-1.5; if people are going to
> update their local libtool, we'd really rather they update to
> libtool-2.2.latest, not a minor update to 1.5.
> 
> My impression was that Ralf was concerned about people who are using,
> say, libtool-2.2.6 which is fairly new, but don't want to update to the
> latest libtool for whatever reason.

Yes.  Typically, the "whatever" reason is that distributions don't
update the version of a package in a stable release.  You won't get
them to jump to 2.2.12 even if they are at 2.2.10 now.

And yes, I'm all fine with the answer being "distros, in case you need =
support, please git cherry-pick $commit" if we find out that works
reasonably well to solve this issue.  So yes, I agree with you on this.
(We might want to make a branch-2.2.X off of some of the release and
cherry-pick the patch there if that helps.)

If anybody is still using 1.5.x, let them do the backporting work.

> Also, I don't think we need try to backport the "=" support from
> libltdl-current, once we implement it, to libltdl-old.  At that point,
> it becomes a distributor question: if you ship .la files with '=', then
> you're requiring that all libltdl clients that access those particular
> .la files must link with libltdl-new.

Ah, but /usr/bin/foo which uses libltdl may want to be able to open
$HOME/local/lib/$package/module.so, no?

So distributors might be interested in fixed libltdl even if their own
libtool might not produce any =.

Of course, the answer may again be as simple as "git cherry-pick ...".

Or, then again, none of the libltdl may want to open .la files that
aren't --mode=finish'ed yet?  That could be a good zero order
approximation.

> I've tested the sysroot branch, with these four patches, as well as:
> 
> [PATCH] improve code for sysroot --mode=finish
> http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00143.html
> 
> [PATCH] Factor the sed command used to make a regex from a literal.
> http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00144.html
> 
> and the attached correction.  I tested on:

> linux native:
> =============
> old: All 106 tests passed (*)
> new: 102 tests behaved as expected. 18 tests were skipped.
> 
> (*) I don't have fortran installed. It's not clear why the fc and f77
> tests aren't shown as 'skipped'.

Can you rerun only those tests with
  make check-local TESTSUITEFLAGS='-k FC -k F77 -v -d -x'

and post output?

> Here is the patch I found necessary:
> 
> 2010-08-15  Charles Wilson  <...>
> 
>       * libltdl/config/ltmain.m4sh (func_mode_finish): Fix logic
>       bug in $opt_dry_run test.

See comments below.

*snip*
> One those are addressed, I think this series would be ready for the
> sysroot branch.  After that, all we have left are: backport patch for
> old libtool+'=' in .la files (discussed above), and support in (new)
> libltdl for '=' in .la files, and we'll be ready to merge to master. I
> think.

I agree with your description of the current state, except that I
haven't re-read all past threads now (will do right before merge),
and except for the issue exposed on AIX which is a real regression,
independent of other bugs found so far, and requires fixing.

> diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
> index 8fc7a35..06dcdf6 100644
> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -1427,7 +1427,11 @@ func_mode_finish ()
>        fi
>  
>        # Remove sysroot references
> -      if $opt_dry_run; then
> +      if ${opt_dry_run-false}; then

I don't get it.  opt_dry_run is initialized unconditionally early in the
libtool script, from general.m4sh, and never unset.  What's the reason
for ${...-default}?

Other than that, the logic fix is obviously good, thanks!
(And I overlooked that in Paolo's patch, too)
You might want to fold this right in.

> +        for lib in $libs; do
> +          echo "removing references to $lt_sysroot and \`=' prefixes from 
> $lib"
> +        done
> +      else
>          tmpdir=`func_mktempdir`
[...]

Cheers,
Ralf