On Fri, Jul 13, 2012 at 06:12:48PM +0200, Jan Stary wrote:
> On Jul 12 19:10:35, Jan Stary wrote:
> > On Jul 12 18:42:23, Marc Espie wrote:
> > > On Thu, Jul 12, 2012 at 04:13:38PM +0200, David Coppa wrote:
> > > > On Thu, Jul 12, 2012 at 4:07 PM, Jan Stary <h...@stare.cz> wrote:
> > > >
> > > > > Index: Makefile
> > > > > ===================================================================
> > > > > RCS file: /cvs/ports/audio/opencore-amr/Makefile,v
> > > > > retrieving revision 1.1.1.1
> > > > > diff -u -p -r1.1.1.1 Makefile
> > > > > --- Makefile 6 Jul 2012 17:21:11 -0000 1.1.1.1
> > > > > +++ Makefile 12 Jul 2012 13:45:06 -0000
> > > > > @@ -25,6 +25,6 @@ MASTER_SITES= ${MASTER_SITE_SOURCEFORGE
> > > > >
> > > > > SEPARATE_BUILD= yes
> > > > > CONFIGURE_STYLE= gnu
> > > > > -USE_LIBTOOL= gnu # oh my.
> > > > > +USE_LIBTOOL= yes
> > > > >
> > > > > .include <bsd.port.mk>
> > > >
> > > > You're late to the party ;)
> >
> > > Sorry, partly my fault. I changed my mind about this one.
> > > If there's a clean
> > > fix for upstream, that's cool. Otherwise, just recognizing -x c and
> > > zapping
> > > it looked safe enough...
> >
> > So, to understand: our libtool now mimicks the practice of throwing out
> > certain options (saving for instance opencore-amr from a linkage failure?)
>
> With -current ports, and USE_LIBTOOL=yes in the Makefile,
> the build fails in the linking stage as follows:
You need -current src. As in really -current.
This got committed yesterday.
cd /usr/src/usr.bin/libtool
cvs update
sudo make install
