[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Charles Wilson
Subject: Re: [PATCH v2 0/3] sysroot followup patches
Date: Mon, 16 Aug 2010 16:27:46 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/

On 8/16/2010 3:27 PM, Ralf Wildenhues wrote:
> 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.)

That sounds like a good plan to me.

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

This, too. :-)

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

Well, it boils down to the following decision tree:

Case #1:
.la file has '=', and is "installed" on the $build filesystem under
Question #1a) Do you expect that libltdl will need to *execute* on
$build, and use these .la files?  There are only three mechanisms for
that behavior, I think:

  a) cygwin->mingw cross compiler, where you *can* actually execute the
     $host (mingw) applications on the $build (cygwin) platform. So, you
     MIGHT want to do so "in place" within the sysroot.

     However, this runs up against the whole issue of dos-style
     prefixes, etc, so that's another bone of contention.  Tabling that,
     and assuming that $sysroot$prefix is
     and the .la files have

     You're left with the following issue: how does the *native* win32
     libltdl figure out that '=' should be replaced NOT by
     which is what you'd get from 'i686-pc-mingw32-gcc -print-sysroot',
     but rather by
        `cygpath -m /usr/$host/sys-root/`
     that is (on my system, but not yours):
        C:/cygwin-1.7/usr/i686-pc-mingw32/sys-root we even care?  To "solve" this problem would introduce a
     lot of hackery, all so that un--finished .la files could be used
     /in situ/ in the $sysroot of a cygwin->mingw cross compiler...

  b) linux->(cygwin,mingw) cross, with WINE support.  Many of the same
     issues above are also in play here, except that you can play games
     with path resolution via the wine path mapping. But that's all
     outside the purview of libtool proper, and we shouldn't really rely
     on it.

  c) multiple ABIs on a single machine. E.g. a 64bit->32bit "cross
     compiler" where the $build machine (64bit hardware) can execute
     binaries restricted to a 32bit ABI.  This is perhaps the most
     straightforward situation. As long as we can get the correct
     sysroot path "into" libltdl (*), simple s/=/$sysroot/ should do
     the trick.

(*) I assume the "correct" sysroot would be the one reported by the
cross compiler with which libltdl was compiled.  You wouldn't want to
contemplate "relocatable" that I could build a package
with a compiler whose sysroot was "/usr/i686-pc-linux-gnu/sys-root" but
you wanted to install my .la files etc in YOUR compiler's sysroot, which
might be "/usr/i585-linux/root".

Case #2)
.la file has '=' and is installed on the $host system in the $prefix. In
this case, libltdl should just ignore the '=' completely.
does libltdl "know" that it's running in case #2, and not case #1(a-c),
where it WOULD need to replace the = with $sysroot (and then do some
sort of $build->$host path conversion aka cygpath?).

Obviously, if the .la files were 'finished' on $host, then there's no
problem; every thing is just status quo, and there are no '=' and no
sysroots.  So, that's obviously the 'safe' approach, for deployed software.

Taking all of this together, I wonder if a good approach might be the
following: libltdl replaces the '=' with the value of the environment
variable LIBLTDL_SYSROOT.  So usually -- with this variable empty -- '='
is just stripped out, which would be typical on the $host system. This
would open up possible exploits -- but if you --finish your .la files,
then there ARE no '=' markers to replace, so you'd be safe.

But, back on the $build platform, developers who want to test, /in
situ/, cross-compiled applications that use libltdl...they could set
this variable as appropriate:
for wine-ish linux->mingw cross compiles;
for wine-ish linux->cygwin cross compiles;
for cygwin->mingw, etc...

>> I've tested the sysroot branch, with these four patches, as well as:
>> [PATCH] improve code for sysroot --mode=finish
>> [PATCH] Factor the sed command used to make a regex from a literal.
>> 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'

Err, sure, but the NEW testsuite did report the correct "skippage":

 29: passing F77 flags through libtool skipped (
 30: passing FC flags through libtool  skipped (
 31: passing GCJ flags through libtool skipped (
 35: F77 convenience archives          skipped (
 36: FC convenience archives           skipped (
 37: Java convenience archives         skipped (
 59: F77 inferred tag                  skipped (
 60: FC inferred tag                   skipped (
 61: GCJ inferred tag                  skipped (

It's just that the OLD testsuite didn't even mention the F77/FC tests:
PASS: tests/tagdemo-undef.test
PASS: tests/tagdemo-make.test
PASS: tests/tagdemo-exec.test
<<<< I expected stuff here >>>>>
All 106 tests passed

That is, I expected:
SKIP: tests/f77demo-static.test
SKIP: tests/f77demo-make.test
SKIP: tests/f77demo-exec.test
SKIP: tests/f77demo-conf.test
SKIP: tests/f77demo-make.test
SKIP: tests/f77demo-exec.test
SKIP: tests/f77demo-shared.test
SKIP: tests/f77demo-make.test
SKIP: tests/f77demo-exec.test
SKIP: tests/fcdemo-static.test
SKIP: tests/fcdemo-make.test
SKIP: tests/fcdemo-exec.test
SKIP: tests/fcdemo-conf.test
SKIP: tests/fcdemo-make.test
SKIP: tests/fcdemo-exec.test
SKIP: tests/fcdemo-shared.test
SKIP: tests/fcdemo-make.test
SKIP: tests/fcdemo-exec.test
106 tests passed
(18 tests skipped)

I've attached what you asked for, but I don't know what it will tell you.

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

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

Ah, sorry. Forgot about the AIX bug.

>> -      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}?

I was just copying the pattern I saw elsewhere. If it's safe to proceed
without the default, then that's fine too.

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

Right, as it is a fix to one of the follow-on patches TO the follow-on
series! and as such hasn't actually been published in the sysroot branch


Attachment: skipped-tests.log
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]