Re: [REBASED PATCH 0/9] Paolo's sysroot patches, rebased plus some fixes

[Charles Wilson]

On 7/26/2010 10:04 AM, Paolo Bonzini wrote:
> On 07/26/2010 01:57 PM, Charles Wilson wrote:
>> These are rebased versions of Paolo's sysroot patches, rebased to
>> 0e01d00c70fe1eba2b746a6bb52e3c9277a4f1ef (Sun Jul 18 17:17:15 2010 +0200)

> Thanks for figuring out all that instead of waiting for me to explain
> it. :(

<g>

>> The new libtool knows how to interpret the '=' when using a sys-root
>> (e.g.
>> a cross compiler).  I haven't yet tested how a NATIVE compiler/libtool
>> reacts when you try to link against an .la file that was created
>> elsewhere
>> using a cross compiler/libtool combo. First things first:
> 
> It should work, lt_sysroot will be empty.

Right, but I was thinking more of an "old" libtool, if it "sees" the '='
decoration in a .la file.  I think you basically end up with a forced
upgrade: if a .la file was generated by the new libtool, from a cross
environment, then any client must have the updated libtool in order to link.

That's an API change (or what passes for one, in libtool land).  It
appears to be a necessary one, but we ought to at least note it in the
NEWS file or something.

>> The C++ problem is basically that the postdeps don't get populated
>> properly.
> 
> That's the only part of libtool.m4 that the patches touch, so either
> patch 9/9 has a stupid typo somewhere (in which case testing the first
> eight patches would pass the tests), or patch 2/9 is introducing a bug
> instead of fixing it.

Well, after the first 7 of 9 (no star trek jokes, please), in native
mode, all of the problematic tests pass (old:
tagdemo-conf.test+tagdemo-make.test; new: 41, 101).

Now, typo or not, 8/9 and 9/9 can't really be treated independently,
since 8/9 will introduce calls to functions that don't exist otherwise:
I get

checking whether the g++ linker (/usr/i686-pc-cygwin/bin/ld.exe)
supports shared libraries... yes
../libtool-sysroot/configure: line 14651: func_stripname: command not found
../libtool-sysroot/configure: line 14651: func_stripname: command not found
../libtool-sysroot/configure: line 14651: func_stripname: command not found

while trying to configure.


I can't simply swap the order, because 9/9 touches lines introduced by 8/9.

So, I can either squash 8 and 9, and treat it atomically, or refactor
the division between the two (e.g. squash them, and then split them
differently).  I think I'll do the latter.


> Thanks again!
> 
> BTW, feel free to squash your changes with mine in subsequent
> submissions, no matter what git does with attribution, so that the
> history stays bisectable.

OK, will do (although I may split 8+9 back apart, with a different
division that maintains bisectability).  As far as I can tell, for
*native* builds it is bisectable throughout the patch series even after
doing the squashes (4+5, 8+9) -- except after the final patch in the
series.  But that doesn't appear to be the case for cross builds, in the
new tests.

But I don't think it was bisectable in cross builds in your original
development either.

So, end result of these manipulations:

(1/8) handle sysroot flags               same as previous 1/9
(2/8) fix buglet                         same as previous 2/9
(3/8) Add --with-sysroot                 same as previous 3/9
(4/8) add a basic sysroot test           squashed prev 4/9 + 5/9
(5/8) teach libtool -L= and -R=          same as previous 6/9
(6/8) handle sysrooted paths when reading dependencies to la files
                                         same as previous 7/9

A tree wound to this point, passes all of the problematic tests I
mentioned originally (new: 41, 101; old: tagdemo-conf+tagdemo-make)

(7/8) Provide func_stripname_cnf shell function to configure
(8/8) emit sysrooted paths when installing .la files

These two are the result of squashing the old 8/9 and 9/9 together, then
re-splitting them differently.  The new 7/8 includes only the defn of
_LT_FUNC_STRIPNAME_CNF, and its AC_REQUIREment by
_LT_SYS_HIDDEN_LIBDEPS([TAGNAME]).  The new 8/8 contains everything else.

A tree wound to just after the new 7/8, passes all of the problematic
tests.  So, whatever the issue, it is introduced by the new 8/8, which
at least narrows down the problem.  For now, I've attached the new 8/8
to this message in case anybody can spot something obvious by
inspection, but I'll (re)post the entire new series tomorrow.

<time passes>

Hmm:

 1  func_replace_sysroot ()
 2  {
 3    case "$lt_sysroot:$1" in
 4    ?*:"$lt_sysroot"*)
 5      func_stripname "$lt_sysroot" '' "$1"
 6      func_replace_sysroot_result==$func_stripname_result
 7      ;;
 8    *)
 9      # Including no sysroot.
10      func_replace_sysroot_result=$1
11      ;;
12    esac
13  }

See anything wrong with line 6?

-    func_replace_sysroot_result==$func_stripname_result
+    func_replace_sysroot_result=$func_stripname_result

So, with that obvious fix...no change  :-(

It still fails (native) new:41,101 and old:tagdemo-conf+tagdemo-make.  I
guess some more eyes on the revised 8/8 would be helpful. Well, on all
of the patches, actually, I guess -- but new 8/8 is the likely locus of
the bug.

--
Chuck

libtool-sysroot-new-8-of-8.patch
Description: Text Data