Re: libtool wrapper PATH

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sat, May 04, 2013 at 07:41:54PM +0900, Masao Uebayashi wrote:
> On Sat, May 4, 2013 at 7:34 PM, Joerg Sonnenberger
> <joerg%britannica.bec.de@localhost> wrote:
> > On Sat, May 04, 2013 at 03:19:01PM +0900, Masao Uebayashi wrote:
> >> On Tue, Apr 16, 2013 at 3:00 PM, Joerg Sonnenberger
> >> <joerg%britannica.bec.de@localhost> wrote:
> >> > On Tue, Apr 16, 2013 at 02:18:00PM +0900, Masao Uebayashi wrote:
> >> >> libtool reorders PATH internally and ignores .wrapper/bin and/or
> >> >> tools/bin somehow.  This patch limits the passed PATH to .wrapper/bin
> >> >> and .tools/bin.  With this commands called from libtool are also
> >> >> jailed.
> >> >
> >> > Can you start by what problem you are trying to solve?
> >>
> >> To strictly follow actual activity done in libtool.  The change is too
> >> strict to checkin the pkgsrc tree, but I'm successfully collecting
> >> interesting observations.
> >
> > It will break some cases like libtool relink. It is intentional that
> > libtool itself is allowed to call the real CC after the buildlink
> > transformations have been done.
> 
> Why wrapper cc doesn't work in that libtool relink case?  I think
> wrapper cc has to behave exactly same as real cc.

Because in that case we *do* want to link against the installed version
without the .buildlink substition.

Joerg