On 07/13/15 00:54, Dave Vandervies wrote:
> Somebody claiming to be Stuart Henderson wrote:
>
>> 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.
>
> ...And, after following up on the suggestions from this thread and
> digging around in /usr/ports/infrastructure, I think I've figured out
> one of the reasons why and come up with a better quick fix.
>
> Newlib (and binutils and gcc, though they don't have this particular
> symptom) does a lot of recursive configuring during the build, and
> doesn't do a very good job of passing things the top-level configure
> was asked to do down to the sub-configures.
> Adding ${CONFIGURE_ENV} to ${MAKE_ENV} so that it affects the environment
> that the sub-configures are actually running in persuades them to pick
> up the overrides that tell them not to use gmkdir.
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/devel/arm-none-eabi/newlib/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Makefile
> --- Makefile 28 May 2015 23:28:26 -0000 1.1.1.1
> +++ Makefile 12 Jul 2015 23:42:48 -0000
> @@ -7,6 +7,13 @@ VERSION= 2.2.0.1
> PKGNAME= ${CONFIG}-newlib-${VERSION}
> #REVISION= 0
>
> +# The build stage for newlib invokes configure (repeatedly), so make
> +# sure the sub-configures run in a suitable environment.
> +# Without this, if coreutils is present at configure time, the
> +# sub-configures will pick up gmkdir as their preferred concurrency-safe
> +# 'mkdir -p'.
> +MAKE_ENV+= ${CONFIGURE_ENV}
> +
> HOMEPAGE= http://sourceware.org/newlib/
>
> MASTER_SITES= ftp://sourceware.org/pub/newlib/
>
>
Builds for me, with coreutils uninstalled mid build.
