Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 01 Jun 2011 16:25:11 +0200
From:      Matthias Andree <matthias.andree@gmx.de>
To:        freebsd-ports@freebsd.org
Cc:        bapt@freebsd.org, amatus@gnu.org
Subject:   Re: lang/guile build fails for me
Message-ID:  <4DE64BC7.5040804@gmx.de>
In-Reply-To: <4DE64546.7070604@FreeBSD.org>
References:  <4DE5D8C9.3020506@icyb.net.ua>	<4DE6244E.1040301@FreeBSD.org>	<20110601114442.GB2223@reindeer.exwg.net>	<4DE6392D.5000106@gmx.de> <20110601131956.GC2223@reindeer.exwg.net> <4DE64546.7070604@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Am 01.06.2011 15:57, schrieb Andriy Gapon:
> on 01/06/2011 16:19 Christoph Moench-Tegeder said the following:
>> Ah, yes, LDFLAGS. The port's Makefile already has
>> LDFLAGS="-L${LOCALBASE}/lib" in $CONFIGURE_ENV, and as guile's configure
> 
> BTW, I think that CONFIGURE_ENV in the port's Makefile better be set with +=, for
> safety.

Sure, but that doesn't help if you add new varname=value assignments for
the same varname - these aren't cumulative as you've shown.

>> is a standard autoconf configure, $LDFLAGS should be picked up (the
>> output of "./configure --help" supports this), but... well, it isn't.
> 
> Looks like LDFLAGS are lost from the environment before configure is run:
> ac_cv_env_LDFLAGS_set=set
> ac_cv_env_LDFLAGS_value=' -rpath=/usr/lib:/usr/local/lib'
> 
> And given the USE_NCURSES workaround posted in this thread, that takes to
> Mk/bsd.ncurses.mk where we have:
> ...
> NCURSES_LDFLAGS+=       -rpath=${NCURSESRPATH}
> 
> .if defined(LDFLAGS)
> LDFLAGS+=${NCURSES_LDFLAGS}
> .else
> LDFLAGS=${NCURSES_LDFLAGS}
> .endif
> 
> CONFIGURE_ENV+=         LDFLAGS="${LDFLAGS}"
> ...
> 
> I think that the above line overrides whatever is set in the port's Makefile.

Plausible - because there would be two different LDFLAGS="mumble"
options in CONFIGURE_ENV, can you check that?

make -V CONFIGURE_ENV   or   make -n do-configure    should reveal that.

Note that LDFLAGS isn't used by bsd.port.mk itself, in contrast to
CPPFLAGS, so that ports can't be expected to set this variable either.

That makes bsd.ncurses.mk incompatible with a few more ports than just
guile I suppose... Cc'ing bapt@.    It appears diligent to look at all
ports that set USE_NCURSES.

(Still the other observed port inconsistencies should get fixed, too.)

-- 
Matthias Andree



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DE64BC7.5040804>