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