Date: Wed, 1 Jun 2011 16:30:25 +0200 From: Baptiste Daroussin <bapt@freebsd.org> To: Matthias Andree <matthias.andree@gmx.de> Cc: amatus@gnu.org, freebsd-ports@freebsd.org Subject: Re: lang/guile build fails for me Message-ID: <BANLkTi=3iD4c3SnDdJJKL8RmHi4WfC-DVQ@mail.gmail.com> In-Reply-To: <4DE64BC7.5040804@gmx.de> 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> <4DE64BC7.5040804@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/6/1 Matthias Andree <matthias.andree@gmx.de>:
> 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=3D"-L${LOCALBASE}/lib" in $CONFIGURE_ENV, and as guile's config=
ure
>>
>> BTW, I think that CONFIGURE_ENV in the port's Makefile better be set wit=
h +=3D, for
>> safety.
>
> Sure, but that doesn't help if you add new varname=3Dvalue assignments fo=
r
> 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=3Dset
>> ac_cv_env_LDFLAGS_value=3D' -rpath=3D/usr/lib:/usr/local/lib'
>>
>> And given the USE_NCURSES workaround posted in this thread, that takes t=
o
>> Mk/bsd.ncurses.mk where we have:
>> ...
>> NCURSES_LDFLAGS+=3D =A0 =A0 =A0 -rpath=3D${NCURSESRPATH}
>>
>> .if defined(LDFLAGS)
>> LDFLAGS+=3D${NCURSES_LDFLAGS}
>> .else
>> LDFLAGS=3D${NCURSES_LDFLAGS}
>> .endif
>>
>> CONFIGURE_ENV+=3D =A0 =A0 =A0 =A0 LDFLAGS=3D"${LDFLAGS}"
>> ...
>>
>> I think that the above line overrides whatever is set in the port's Make=
file.
>
> Plausible - because there would be two different LDFLAGS=3D"mumble"
> options in CONFIGURE_ENV, can you check that?
>
> make -V CONFIGURE_ENV =A0 or =A0 make -n do-configure =A0 =A0should revea=
l 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@. =A0 =A0It appears diligent to look at al=
l
> ports that set USE_NCURSES.
>
> (Still the other observed port inconsistencies should get fixed, too.)
>
> --
> Matthias Andree
>
If someone comes with a better solution for USE_NCURSES please be
aware that the solution will also fits with USE_OPENSSL
so that the job won't be done twice.
Anyway I think the fix is not to add anyflags to configure_env
manually (would it be from USE_* of in the ports itself)
Maybe LDFLAGS should always be appended to CONFIGURE_ENV has it has
been done for CPPFLAGS.
regards,
Bapt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=3iD4c3SnDdJJKL8RmHi4WfC-DVQ>