On 2015/07/12 16:09, Dave Vandervies wrote:
> Somebody claiming to be Antoine Jacoutot wrote:
> > In case anyone is interested, devel/arm-none-eabi/newlib broke in my
> > bulk because gmkdir was detected at configure time (and junked by dpb
> > later on).
>
> Quick fix: Make coreutils an explicit build dependency so dpb knows
> something is using it.
> I have a list of things to look at in devel/arm-none-eabi/* as time and
> energy become available, and looking into whether there's a better way
> to handle this has been added to that list.
>
> In general, is there a way to identify things that would get picked up if
> they're there but that wouldn't normally be installed on the system I'm
> working on that works better than waiting for somebody else to notice?
> And is there a generally-applicable way to deal with it?
Generally, read configure output. For some common things (in particular
programs from coreutils) we have scaffolding to prevent autoconf from
picking them up, but the arm-none-eabi ports are too complex for the
normal things to work.
> diff -u -p -r1.1.1.1 Makefile
> --- Makefile 28 May 2015 23:28:26 -0000 1.1.1.1
> +++ Makefile 12 Jul 2015 19:53:42 -0000
> @@ -18,6 +18,11 @@ BUILD_DEPENDS= devel/arm-none-eabi/binut
> ${RUN_DEPENDS}
> RUN_DEPENDS= devel/arm-none-eabi/gcc-linaro
>
> +# coreutils is not a hard build dependency, but gmkdir will be picked up by
> +# configure if it's there. So make it an explicit dependency to prevent dpb
> +# from removing it before we've used it for the install step.
> +BUILD_DEPENDS+= sysutils/coreutils
> +
> # cope with user settings in /etc/mk.conf
> MAKE_FLAGS= CFLAGS="-I${LOCALBASE}/include"
> USE_GMAKE= Yes
yeah... not perfect but I think it's the best option for now.
