On Sat, Nov 18, 2017 at 04:48:12PM -0500, Paul Smith wrote:
> One way to fix this would be to change the second #if line above to be:
>
> # if _GNU_GLOB_INTERFACE_VERSION >= GLOB_INTERFACE_VERSION
>
> and see if that works.
Yes! This solves the issue and it also solves the __stat issues as
well
On Sat, 2017-11-18 at 21:19 +, Earnestly wrote:
> [I've also found that `make update' is apparently subject to `make -j4'
> race conditions resulting in errors like:
>
> wget: unable to resolve host address ‘cvs.savannah.gnu.org’
> make: *** [Makefile;1584: get-doc/fdl.texi] Error 4
I
On Sat, Nov 18, 2017 at 01:54:47PM -0500, Paul Smith wrote:
> That change was made to make's internal usage of glob so that it works
> with the latest glibc without errors: before that change if you tried
> to use the system glibc glob and it had the newest glibc, make could
> crash.
Ah yes, I rem
On Sat, 2017-11-18 at 18:35 +, Earnestly wrote:
> > Also curious: why does the build decide to compile/link the version
> > of glob that comes with make? If you're using glibc then it should
> > use the one that comes with glibc instead.
>
> Wasn't this specifically done to workaround make us
On Sat, Nov 18, 2017 at 01:02:00PM -0500, Paul Smith wrote:
> Thanks for the good info on your version of make and GCC... but... can
> you provide details on what operating system you're using?
I'm currently using Arch Linux currently on kernel 4.13.11 with a lot of
packages built from latest deve
On Sat, 2017-11-18 at 16:17 +, Earnestly wrote:
> However I am now getting:
Thanks for the good info on your version of make and GCC... but... can
you provide details on what operating system you're using? I can't
reproduce this on any of my systems so I'm just curious. Is it just
the newer
On 11/18/17, Paul Smith wrote:
> On Tue, 2017-11-07 at 13:43 -0500, Nick Bowler wrote:
>> Is this behaviour intended? I noticed the manual says "make may take
>> shortcuts that do not affect the results" but in this instance a change
>> in results is definitely observed.
>
> Well, technically "co
On Thu, Nov 02, 2017 at 11:40:50AM +, Earnestly wrote:
> Hi,
>
> For reference my system has the following versions and environs:
>
> * gcc 7.2.0
> * glibc 2.26.9000 (commit 2fac6a6cd5)
> * make 4.2.90 (commit baa57d2) [patched, see below]
>
> * CPPFLAGS -D_FORTIFY_SOURCE=2
> * CFLAGS -march=x8
On Sat, Nov 18, 2017 at 09:35:18AM -0500, Paul Smith wrote:
> Pushed a fix for this.
Thanks, seems to be working again. All that's left is the undefined
alloca reference errors.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/l
Hi all.
This morning I pushed a batch of changes to the GNU make package build
to remove a bunch of older, outdated methods of building GNU make. I
removed the NMakefiles, SMakefiles, Visual Studio project files, and
some of the outdated .bat files.
The goal is to provide three package build cap
On Tue, 2017-11-07 at 13:43 -0500, Nick Bowler wrote:
> Is this behaviour intended? I noticed the manual says "make may take
> shortcuts that do not affect the results" but in this instance a change
> in results is definitely observed.
Well, technically "command" is not a valid POSIX shell built-
On Fri, 2017-11-03 at 15:24 +, Earnestly wrote:
> On Fri, Nov 03, 2017 at 09:50:50AM -0400, Paul Smith wrote:
> > I'm not quite sure how to answer that question: definitely I didn't
> > intend the test to fail :).
>
> Ah sorry, I meant this in regards to whether the test was functioning
> corr
12 matches
Mail list logo
