I've had a proper look at it, and the problem comes with packages
	that have constructs of the form:

		.if ${OBJECT_FMT} == "ELF"

	Either we should:

	    a) Fix all such Makefiles (around 34)
 	    b) Catch OBJECT_FMT not being set and fix it in bsd.pkg.mk.
	       How about using OBJECT_FMT!= make show-shlib-type in a
	       .if !defined(OBJECT_FMT)?

		David/absolute		-- www.netbsd.org: No hype required --


On Fri, 27 Apr 2001, Alistair Crooks wrote:

> On Thu, Apr 26, 2001 at 05:46:09PM +0100, David Brownlee wrote:
> > 	pkgsrc currently assumes the base system sets OBJECT_FMT.
> > 	This is not the case in 1.3 - and in addition to producing
> > 	various warning messages it breaks the install in some cases
> > 	- I have a 1.3 machine on which I cannot install
> > 	imap-uw-2000.0.3nb1 unless I have installed libtool with
> > 	OBJECT_FMT manually set.
>
> The only places where I see OBJECT_FMT used in bsd.pkg.mk, there are
> checks around it - if OBJECT_FMT is undefined, then you will just not
> have your shared libs checked in the check-shlibs target, and the
> dependency checks will either exit or warn depending on the value of
> FATAL_OBJECT_FMT_SKEW.
>
> Please note that I'm not speaking for libtool here.
>
> > 	I think we should test for OBJECT_FMT and set it for older NetBSD
> > 	systems, but what is the best way - a switch table similar to that
> > 	in bsd.own.mk, or some nasty 'file' command on the pkg_install
> > 	binary?
>
> If you're really interested in what type of shared lib will be made on
> the machine, then you can use:
>
> 	make show-shlib-type
>
> Regards,
> Alistair
>