Subject: pkg/26542: assorted pkg breakage with bsd.own.mk rev. 1.422
To: None <gnats-bugs@gnats.NetBSD.org>
From: None <jbernard@mines.edu>
List: pkgsrc-bugs
Date: 08/03/2004 16:34:59
>Number:         26542
>Category:       pkg
>Synopsis:       assorted pkg breakage with bsd.own.mk rev. 1.422
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Aug 03 22:36:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Jim Bernard
>Release:        NetBSD 2.0G, July 31 2004 source, pkgsrc of same or later date
>Organization:
>Environment:
System: NetBSD 2.0G Sat Jul 31 17:03:53 MDT 2004 i386
Architecture: i386
Machine: i386
>Description:
	In PR 26524 I described a build failure of print/gv, which I
	ultimately traced (described in an addendum to the PR) to
	an incompatibility of pkgsrc make files with a recent change
	to bsd.own.mk (revision 1.422) that imported assignments of
	LIBxxx variables that had previously been in bsd.prog.mk.
	In the case of gv, the variable LIBXAW was set by bsd.own.mk,
	preventing its proper assignment in x11/Xaw3d/buildlink3.mk,
	which ultimately caused the gv build failure.

	I've also found one other case so far where the same change to
	bsd.own.mk resulted in a package build failure.  That is
	devel/libgnome.  But the problem is actually not there---it's
	in audio/esound.  When esound is built with rev. 1.422 of
	bsd.own.mk in place, the variable LIBOSSAUDIO is set to
	/usr/lib/libossaudio, and the esound library link command looks
	like:

	  /bin/sh ./libtool --mode=link gcc  -O2 -I/usr/pkg/include -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -o libesd.la -rpath /usr/pkg/lib -version-info 2:34:2 -no-undefined esdlib.lo esdmgr.lo esdfile.lo esd_config.lo  audio.lo genrand.lo util.lo -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -laudiofile -lm  /usr/lib/libossaudio.a

	And libtool whines:

	  *** Warning: Trying to link with static lib archive /usr/lib/libossaudio.a.
	  *** I have the capability to make that library automatically link in when
	  *** you link to this library.  But I can only do this if you have a
	  *** shared version of the library, which you do not appear to have
	  *** because the file extensions .a of this argument makes me believe
	  *** that it is just a static archive that I should not used here.

	The resulting libesd's then cause the devel/libgnome link step
	to fail:

	  /usr/local/src/netbsd/pkgsrc/devel/libgnome/work.roc/.buildlink/lib/libesd.so: undefined reference to `_oss_ioctl'

	So, I replaced revision 1.422 of bsd.own.mk with revision 1.421
	and rebuilt esound.  Then the link step looked like:

	  /bin/sh ./libtool --mode=link gcc  -O2 -I/usr/pkg/include -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -o libesd.la -rpath /usr/pkg/lib -version-info 2:34:2 -no-undefined esdlib.lo esdmgr.lo esdfile.lo esd_config.lo  audio.lo genrand.lo util.lo -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -laudiofile -lm  -lossaudio

	Note the "-lossaudio" added by mk/ossaudio.buildlink3.mk, instead
	of the /usr/lib/libossaudio.a added by bsd.own.mk.  This time there
	was no warning from libtool.  And a subsequent build of devel/libgnome
	was then successful (with either rev. 1.421 or rev. 1.422 of
	bsd.own.mk).

	So, now it appears that there is a general conflict between the
	assignments of LIBxxx variables in bsd.own.mk (which are path
	names to static libraries) and assignments to variables of the
	same name in pkgsrc make files (which are often linker flags),
	the latter assignments apparently generally being conditional.
	I don't know yet how many of these will prove to be a problem.
	So far, at least LIBXAW and LIBOSSAUDIO have caused trouble.

>How-To-Repeat:
	Install a /usr/share/mk tree containing rev. 1.422 of bsd.own.mk
	(in was added July 30).  Build esound.  Try to build libgnome.
	OR: build Xaw3d and try to build gv.  (In both cases, there
	are other prerequisites that will have to be built.)

>Fix:
	As I mentioned in an addendum to PR 26524, I'm not at all sure
	what's the best course of action.  I called this a pkg PR, since
	that's where the breakage is seen, but it's possible that the
	ultimate solution will be to change bsd.own.mk.  Other possibilities
	include adapting the pkgsrc make files to assign the various
	LIBxxx variables that it uses unconditionally, so that the
	assignments in bsd.own.mk don't interfere.  Another would be to
	use a different set of variable names in pkgsrc.
>Release-Note:
>Audit-Trail:
>Unformatted: