Message-ID: <4C5139CD.3010702@cwilson.fastmail.fm>
Date: Thu, 29 Jul 2010 04:20:29 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: problem with PATH set by libtool for uninstalled pixman library
References: <4C5075E3 DOT 9020903 AT dronecode DOT org DOT uk>
In-Reply-To: <4C5075E3.9020903@dronecode.org.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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