lang/guile build fails for me

Matthias Andree matthias.andree at
Wed Jun 1 14:25:14 UTC 2011

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/ where we have:
> ...
> .if defined(LDFLAGS)
> .else
> .endif
> ...
> 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 itself, in contrast to
CPPFLAGS, so that ports can't be expected to set this variable either.

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

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

Matthias Andree

More information about the freebsd-ports mailing list