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/
--
Dave Vandervies
[email protected] / [email protected]
Plan your future! Make God laugh!
