On Tue, Mar 13, 2001 at 02:15:13PM +1100, Simon Burge wrote:
> Ignatios Souvatzis wrote:
> 
> > Hi,
> > 
> > in short: madplay 0.12.5b as built form pkgsrc is dumping core on
> > a 1.5 DNARD system.
> > 
> > I forced it to statically compile in libmad.a instead of using the shared
> > library, and it works. Now, whats broken... madplay, the package, the compiler,
> > the linker, ld.so_aout, libtool?
> 
> madplay's own libtool doesn't know about shared libraries, so
> the following at least produces something that works on arm32
> (just ignore the warnings about not finding libmad.so.0.0):
> 
> Index: Makefile
> ===================================================================
> RCS file: /cvsroot/pkgsrc/audio/madplay/Makefile,v
> retrieving revision 1.11
> diff -d -p -u -r1.11 Makefile
> --- Makefile	2001/02/16 13:30:46	1.11
> +++ Makefile	2001/03/13 03:07:17
> @@ -15,7 +15,9 @@ BUILD_DEPENDS+= msgfmt:../../devel/gette
>  
>  GNU_CONFIGURE=	YES
>  USE_LIBINTL=	YES
> +.if (${MACHINE_ARCH} != "arm32")
>  USE_LIBTOOL=	YES
>  LTCONFIG_OVERRIDE=	${WRKSRC}/ltconfig
> +.endif
>  
>  .include "../../mk/bsd.pkg.mk"
> 
> I did try
> 
> 	CONFIGURE_ARGS=--disable-shared
> 
> but while it did get passed to ./configure it still made shared
> libraries.
> 
> This obviously falls into the "gross hack" department, but since this
> is really the only usable mp3 player on a shark, should I commit it
> (with some appropriate XXX comments)?

In the absence of a decent solution, and since madplay is the only
non-FP mp3 player that we can find, please do what you suggest above,
including the XXX comments.

But I really would like to see a long-term, decent fix to the problem,
too.

Thanks,
Al