On Saturday 08 July 2006 11:07, Jonathan Perkin wrote:
> 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).


Well I won't claim to know much about the wrapper framework but I had a poke 
and I think the problem is that the wrapper stuff expects $PKG_CPP to be set 
(by the compiler stuff) but it is only set for gcc and then only if cpp 
exists in the same directory as gcc.  If $PKG_CPP is not set and no cpp is on 
the path then no cpp wrapper is created but the rest of the framework expects 
that it has.

The following patch fixes the problem for me on Solaris while not breaking 
what currently happens on NetBSD.


Index: compiler.mk
===================================================================
RCS file: /src/cvs/netbsd/pkgsrc/mk/compiler.mk,v
retrieving revision 1.55
diff -u -r1.55 compiler.mk
--- compiler.mk	27 Jul 2006 20:07:06 -0000	1.55
+++ compiler.mk	3 Aug 2006 22:32:48 -0000
@@ -127,6 +127,10 @@
 .endfor
 .undef _compiler_
 
+.if !defined(PKG_CPP)
+PKG_CPP:=${CPP}
+.endif
+
 # Strip the leading paths from the toolchain variables since we manipulate
 # the PATH to use the correct executable.
 #


cheers
mark