Subject: Wrapper problem
To: None <email@example.com>
From: Jonathan Perkin <firstname.lastname@example.org>
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.
- 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).
Jonathan Perkin The NetBSD Project