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. > As you can see, the install path appears before .libs in the PATH the > libtool wrapper constructs, so the installed version from a previous > build is used, rather than the uninstalled version we want to test. > > I'm not quite clear why the install path is being added at all, I don't > think libpixman has any dependencies which it needs to find there (at > least in the cygwin build) But libtool doesn't know that, at that particular point in the code. > I notice if I add '-bindir' to the LDFLAGS, this seems to rearrange the > order of things added to PATH so things work, but the description of > -bindir is a bit opaque to me, so I'm not sure if that's the correct > solution. > No, bindir is used with you are installing the libtool .la in a non-sibling directory of the eventual DLL location. E.g. /usr/bin/foo.dll /usr/lib/foo.la this is fine; there is no need for -bindir. However, this: /usr/bin/foo.dll /usr/lib/foo/private/foo.la is not fine, since the relative path from .la to .dll is NOT ../bin/. So, you'd use -bindir in this case. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple