Re: w32 pending?

[Charles Wilson]

On 9/16/2010 2:55 PM, Ralf Wildenhues wrote:
> This looks ok, but wouldn't the shell wrapper need this as well,
> seeing that it could be run on w32 too (IIRC)?

You're right.  I had looked at this before, and erroneously concluded
that the shell wrapper was DTRT.  But...it isn't.  Also, my changelog is
wrong, as is the /*comment*/ (but the guts of the patch is right)

It's actually $dllsearchpath that's causing problems; $temp_rpath needs
to "win" because it is manipulated by libtool to include the directory
of linked .la files (including the ones linked from $OBJDIR). The
"issue" with user-specified -rpath's is a red herring; those aren't used
by the wrapper system at all; $temp_rpath is for *temporary*
rpaths...like $OBJDIR.  (Oddly, I got this "right" in my description of
the problem at http://cygwin.com/ml/cygwin/2010-07/msg00608.html).

Just as a reminder, here's how these two _VALUEs are assigned:

func_to_host_path "$dllsearchpath:"
const char * EXE_PATH_VALUE   = "$func_to_host_path_result";

func_to_host_path "$temp_rpath"
const char * LIB_PATH_VALUE   = "$func_to_host_path_result";

So, what happens WITH this patch, is $dllsearchpath is prepended first,
then $temp_rpath (so $temp_rpath wins) -- which is what we want
(contrary to my earlier /*comments*/.)


Here are the variable values for the mdemo wrapper:

const char * LIB_PATH_VARNAME = "PATH";
const char * LIB_PATH_VALUE   =
"/usr/src/packages/libtool/22/libtool-2.2.11a-1/build/tests/mdemo/.libs:";
 // e.g. $temp_rpath

const char * EXE_PATH_VARNAME = "PATH";
const char * EXE_PATH_VALUE   =
"/usr/src/packages/libtool/22/libtool-2.2.11a-1/build/tests/mdemo/.libs:/usr/src/packages/libtool/22/libtool-2.2.11a-1/build/_inst-mdemo/lib:/usr/src/packages/libtool/22/libtool-2.2.11a-1/build/_inst-mdemo/bin:";
 // e.g. $dllsearchpath

Now, in THIS instance, $OBJDIR appears in both (and is first in the
latter var), so it wouldn't matter whether EXE_PATH_VALUE or
LIB_PATH_VALUE ends up "first" in the $PATH (e.g. is prepended last).

Per John's original report, we actual had (reconstructed from the debug
output):

const char * LIB_PATH_VALUE = "/opt/jhbuild/build/pixman/pixman/.libs:";
// e.g. $temp_rpath

const char * EXE_PATH_VALUE =
"/opt/jhbuild/install/lib:/opt/jhbuild/install/bin:/opt/jhbuild/build/pixman/pixman/.libs:";
// e.g. $dllsearchpath

It looks like $OBJDIR *also* shows up in both vars, but the order within
$dllsearchpath varies.  However, I haven't seen a case where $temp_rpath
doesn't start with $OBJDIR, even when linking against various .la's from
various installed/non-installed locations, or when using various -L
arguments.  This isn't to say there IS no such case, just that *I* don't
recall seeing one.



*Currently*, in the shell wrapper, here's what is going on:
    $shlibpath_var=\"$temp_rpath\$$shlibpath_var\"
    PATH=$dllsearchpath:\$PATH


That's not right; we want $temp_rpath to win here, too.

> Also, of course, testsuite exposure should follow eventually.

Obviously.  If I can get myself so confused while doing the right thing,
we really need a testsuite addition to keep it fixed. :-)

--
Chuck