Hello,

I've been investigating problems that have been seen with shared c++ 
libraries not being built on solaris with pkgsrc when using the sun 
studio compilers.  I believe I have tracked it down to the following.


The configure script that is part of devel/libtool-base looks at the 
basename of the compiler to make decisions.

This means that when we tell libtool's configure script that we are using

/usr/pkgsrc/devel/libtool-base/work/.wrapper/bin/g++

instead of

/usr/pkgsrc/devel/libtool-base/work/.sunpro/bin/CC

then we throw off a bunch of decisions.  It appears that this issue 
can/will affect other compilers and other operating systems too besides 
solaris+sunpro.

now in ${WRKSRC}/libtool.m4, there is:

# _LT_CC_BASENAME(CC)
# -------------------
# Calculate cc_basename.  Skip known compiler wrappers and cross-prefix.
AC_DEFUN([_LT_CC_BASENAME],
[for cc_temp in $1""; do
   case $cc_temp in
     compile | *[[\\/]]compile | ccache | *[[\\/]]ccache ) ;;
     distcc | *[[\\/]]distcc | purify | *[[\\/]]purify ) ;;
     \-*) ;;
     *) break;;
   esac
done
cc_basename=`$echo "X$cc_temp" | $Xsed -e 's%.*/%%' -e "s%^$host_alias-%%"`
])


This macro is used to extract the comiler basename before doing the 
checks I mentioned.  So just as a test, I modified the last bit to be:


# Return the actual command name, not our pkgsrc wrapper name because 
several
# decisions are made only based on compiler names
new_cc_temp=`$cc_temp --wrappee-name 2>/dev/null` || new_cc_temp="$cc_temp"
cc_basename=`$echo "X$new_cc_temp" | $Xsed -e 's%.*/%%' -e 
"s%^$host_alias-%%"`


And I modified pkgsrc/mk/wrapper/wrapper.sh to add this --wrappee-name 
argument.

diff -u -2 -r1.10 wrapper.sh
--- wrapper.sh  9 Dec 2006 12:11:28 -0000       1.10
+++ wrapper.sh  12 Dec 2006 20:39:30 -0000
@@ -80,4 +80,8 @@

  cmd="@WRAPPEE@"
+case "$*" in
+*--wrappee-name*) $echo $cmd ; exit ;;
+esac
+
  libs=""
  rellpath=""

So if I make this change to libtools configure script I find that indeed 
I can now build shared c++ libraries which fixes critical "trunk" 
packages like databases/db4 and devel/ncurses.

My question now is if anyone sees a better way?  The trick is I don't 
want to just put a solaris+sunpro only bandaid there, I want to teach 
libtool generally about our compiler wrappers.

Comments?  I'd like to get something in soon, but at the same time I 
don't really want to touch the wrapper scripts or libtool.

-Dan