Shall I commit the previous "big hammer" fix then?
On Tue, Jul 14, 2015, 15:46 Christian Weisgerber wrote:
> On 2015-07-13, Dave Vandervies wrote:
>
> > I went with the bigger hammer to make sure all of the configure overrides
> > would get through and not just the one that was observed causing
On 2015-07-13, Dave Vandervies wrote:
> I went with the bigger hammer to make sure all of the configure overrides
> would get through and not just the one that was observed causing problems
> when it got lost.
I agree.
Also, check how many config.guess files are hiding in subdirectories
set MOD
Somebody claiming to be Antoine Jacoutot wrote:
> I think this is less of a hammer:
I went with the bigger hammer to make sure all of the configure overrides
would get through and not just the one that was observed causing problems
when it got lost. But I don't have strong feelings about which s
> > > 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 - 1.1.1.1
> > > ++
On Sun, Jul 12, 2015 at 10:06 PM Nigel Taylor
wrote:
> 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 autoco
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
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,
On Sun, Jul 12, 2015 at 11:11:09PM +0100, Nigel Taylor wrote:
> On 07/12/15 13:27, 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).
> >
> > <...>
> > checking for a
On 07/12/15 13:27, 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).
>
> <...>
> checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p
> <...>
> Making install
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
On 2015-07-12, Dave Vandervies 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.
Y
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
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).
<...>
checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p
<...>
Making install in .
gmake[3]: Entering directory
'/exopi-obj/pobj/arm-
13 matches
Mail list logo
