The following reply was made to PR pkg/29215; it has been noted by GNATS.

From: "Johnny C. Lam" <jlam@NetBSD.org>
To: Min Sik Kim <minskim@NetBSD.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: pkg/29215: lang/tcl build fails on MacOS X 10.[12].x after mk/wrapper changes
Date: Mon, 14 Feb 2005 20:06:46 +0000

 --u3/rZRmxL6MmkK24
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Mon, Feb 14, 2005 at 11:11:11AM -0600, Min Sik Kim wrote:
 > 
 > On Feb 14, 2005, at 11:01 AM, Johnny C. Lam wrote:
 > 
 > >Min Sik Kim wrote:
 > >>On Feb 14, 2005, at 10:36 AM, Johnny C. Lam wrote:
 > >>>If anyone has a .work.log that I could look at for the above error, 
 > >>>that would help greatly.  The proposed patch is only hiding some 
 > >>>deeper issue that should be fixed.
 > >>It is available at the following URL:
 > >>http://www.netbsd.org/~minskim/pkgsrc/logs/work.log
 > >
 > >Thanks!  I've discovered that the problem is that the libtool wrapper 
 > >is being passed "-install_name /Volumes/UFS/pkg/lib/libtcl84.dylib" to 
 > >give to the compiler.  Could you also point me to a URL of 
 > >/usr/pkg/bin/libtool on a Darwin machine?  I need to examine how 
 > >-install_name is handled within the installed libtool script.
 > 
 > libtool from libtool-base-1.5.10nb9:
 > 
 > http://www.netbsd.org/~minskim/pkgsrc/logs/libtool
 
 Thanks for all of the information that you've provided.
 
 I've attached a patch that teaches the libtool wrapper about the same
 types of transformations that the compiler wrapper already knows to
 do.  This should protect "-install_name ..." from wrapper transformations
 within the libtool wrapper.  Please let me know if this fixes the
 problem.
 
 Software that properly use libtool don't pass an explicit "-install_name
 ..." because libtool always generates its own such argument when
 building the (Darwin) shared library.  However, I appreciate that not
 every piece of software, including the ones like lang/tcl that pkgsrc
 converted to use libtool, will use libtool in the documented fashion.
 Longer term, those packages should be fixed properly, but we will still
 need this patch to deal with other types of compiler-specific
 transformations.
 
 	Cheers,
 
 	-- Johnny Lam <jlam@NetBSD.org>
 
 --u3/rZRmxL6MmkK24
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="wrapper.patch"
 
 Index: bsd.wrapper.mk
 ===================================================================
 RCS file: /cvsroot/pkgsrc/mk/wrapper/bsd.wrapper.mk,v
 retrieving revision 1.19
 diff -u -r1.19 bsd.wrapper.mk
 --- bsd.wrapper.mk	18 Jan 2005 17:25:13 -0000	1.19
 +++ bsd.wrapper.mk	14 Feb 2005 20:00:14 -0000
 @@ -245,6 +245,7 @@
  _WRAP_ARG_PP.CXX=	${_WRAP_ARG_PP.CC}
  _WRAP_CACHE_BODY.CXX=	${_WRAP_CACHE_BODY.CC}
  _WRAP_TRANSFORM.CXX=	${_WRAP_TRANSFORM.CC}
 +_WRAP_ARG_PP.LIBTOOL=	${_WRAP_ARG_PP.CC}
  .endif
  
  .if !empty(PKGSRC_COMPILER:Mmipspro-ucode)
 @@ -294,6 +295,7 @@
  _WRAP_ARG_PP.CC=	${WRAPPER_TMPDIR}/arg-pp-darwin-gcc
  _WRAP_ARG_PP.CXX=	${_WRAP_ARG_PP.CC}
  _WRAP_ARG_PP.LD=	${_WRAP_ARG_PP.CC}
 +_WRAP_ARG_PP.LIBTOOL=	${_WRAP_ARG_PP.CC}
  .elif ${OPSYS} == "UnixWare"
  _WRAP_CMD_SINK.CC=	${WRAPPER_TMPDIR}/cmd-sink-unixware-gcc
  _WRAP_CMD_SINK.CXX=	${_WRAP_CMD_SINK.CC}
 
 --u3/rZRmxL6MmkK24--