On 7/28/2010 2:24 PM, Jon TURNEY wrote:
I have a tinderbox which does daily builds of the X.Org stack for
cygwin, and I've come across a something I don't understand with the way
libtool is working when building the pixman library, and I hope someone
can shed a bit of light.
(lt_update_lib_path) modifying 'PATH' by prepending
'/opt/jhbuild/build/pixman/pixman/.libs:'
(lt_setenv) setting 'PATH' to
'/opt/jhbuild/build/pixman/pixman/.libs:/home/jon/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0/:/bin'
(lt_update_exe_path) modifying 'PATH' by prepending
'/opt/jhbuild/install/lib:/opt/jhbuild/install/bin:/opt/jhbuild/build/pixman/pixman/.libs:'
(lt_setenv) setting 'PATH' to
'/opt/jhbuild/install/lib:/opt/jhbuild/install/bin:/opt/jhbuild/build/pixman/pixman/.libs:/opt/jhbuild/build/pixman/pixman/.libs:/home/jon/bin:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0/:/bin'
This is because the wrapper prepends the rpath onto $$LIB_PATH_VARNAME,
and prepends the dllsearchpath onto $$EXE_PATH_VARNAME.
But, since LIB_PATH_VARNAME==EXE_PATH_VARNAME on cygwin (both are
"PATH") that's basically saying:
PATH=$rpath:${PATH}
PATH=$dllsearchpath:${PATH}
I think it was a deliberate choice (e.g. on linux) for the wrapper to
add the $rpath to $LD_RUN_PATH, but...it's not such a great idea for win32.
This is a case where the wrapper exe was trying to do exactly what the
wrapper script used to do -- without considering whether the wrapper
script was doing the right thing, for this platform.
I think a patch to simply swap the order of these two assignments would
be fine (e.g. do $dllsearchpath first, then make sure it gets pre-empted
by $rpath). On *nix it wouldn't matter, since the two variables are
DISTINCT vars.