Subject: Wrapper problem
To: None <tech-pkg@netbsd.org>
From: Jonathan Perkin <jonathan@perkin.org.uk>
List: tech-pkg
Date: 07/08/2006 00:07:46
So, the pkgsrc branch is screwed on Solaris for the second consecutive
release, this time with a cpp issue in converters/libiconv which kinda
breaks a few dependancies...

The problem appears to be:

  - bsd.wrapper.mk depends on $PATH, and only creates wrappers for
    programs it can find that way.  It ignores passing them to the
    environment via e.g. $CPP

  - we recommend Solaris users set CPP=/usr/ccs/lib/cpp in their
    mk.conf, as it isn't in the default path and it's not really that
    wise to add a lib directory to your $PATH.  This has worked for a
    long time, until..

  - CONFIGURE_ENV correctly passes the full path to $CPP down, but the
    wrapper stuff intervenes and substitutes it for the basename to
    make it pick up the wrapper script instead (after pre-pending the
    wrapper dir to $PATH).

  - stuff bombs because "cpp" doesn't exist.

This appears to work by chance for e.g. SunPro, where the binaries are
installed in /opt somewhere and aren't available in the normal $PATH.
They are only picked up because elsewhere in the wrapper
infrastructure further wrappers are created and added to the $PATH
which point to the real binaries.

Solutions:

  - Force users to add /usr/ccs/lib (or /usr/lib) to their $PATH (ick)

  - Don't create a wrapper for cpp, so it doesn't get mangled on the
    way through to configure and "just works" like it used to before.

  - Support env vars as well as $PATH in bsd.wrapper.mk

  - Special-case certain compiler/tool directories on $OPSYS and add
    them to search path for bsd.wrapper.mk to look for stuff in, so it
    doesn't pollute $PATH but provides easy way to add extra locations

I don't know enough about the nuances and design of the wrapper
framework to make a judgement call on this one, so I'm opening this
one up for those better qualified to resolve the issue (and probably
come up with a better solution than any I've proposed).

Thanks,

-- 
Jonathan Perkin                                     The NetBSD Project
http://www.perkin.org.uk/                       http://www.netbsd.org/