>Number:         19495
>Category:       pkg
>Synopsis:       librep vs. buildlink2: bogus libtool for librep users
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 22 07:00:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Bill Sommerfeld
>Release:        NetBSD 1.6K
>Organization:
none
>Environment:

System: NetBSD syn.hamachi.org 1.6K NetBSD 1.6K (GENERIC_LAPACPI) #70: Sat Dec 21 12:49:17 EST 2002 sommerfeld@syn.hamachi.org:/usr/src/sys/arch/i386/compile/GENERIC_LAPACPI i386
Architecture: i386
Machine: i386
>Description:
	x11/rep-gdk failed to build with very screwy-looking build
	errors (referencing pkgsrc/lang/librep/work.i386/.buildlink
	...)

	it appears that the librep package installs its own libtool
	and a rules.mk file which invokes it into 
	/usr/pkg/libexec/rep/i386--netbsdelf/

	however, what actualy get installed is the buildlink2 libtool
	wrapper which references the (possibly long gone) lang/librep
	work directory.

	packages which depend on librep look for the installed
	rules.mk, end up using the bogon libtool, and go down in flames.

>How-To-Repeat:
	try to build x11/rep-gdk

>Fix:
	Unknown.  

	I've worked around the build failure with the following hack
	but this is clearly not the right answer long-term (not
	LOCALBASE-independant)

--- rules.mk.sh.~1~	Mon Jan 15 23:17:48 2001
+++ rules.mk.sh	Sun Dec 22 09:47:47 2002
@@ -12,7 +12,7 @@
 repcommonexecdir=$repcommonexecdir
 rpath_repcommonexecdir=$repcommonexecdir
 
-rep_LIBTOOL=\$(repcommonexecdir)/libtool
+rep_LIBTOOL=/usr/pkg/bin/libtool
 rep_INSTALL_ALIASES=\$(repcommonexecdir)/install-aliases
 
 # use this like:


>Release-Note:
>Audit-Trail:
>Unformatted: