[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: libtool wrapper PATH
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.
Main Index |
Thread Index |