Re: GNU make 3.81.90 prerelease available

Ping! > Date: Fri, 09 Jul 2010 12:06:09 +0300 > From: Eli Zaretskii > Cc: bug-make@gnu.org > > > From: Paul Smith > > Date: Wed, 07 Jul 2010 01:55:49 -0400 > > > > The first prerelease of the next version of GNU make is available on the > > alpha FTP site (or via HTTP): > > > > > > 98fd14ffe

About install the xdebug.

Dear, when I restart the apache , I get the error logs as follow: Warning: Xdebug MUST be loaded as a Zend extension in Unknown on line 0 Warning: Xdebug MUST be loaded as a Zend extension in Unknown on line 0 Failed loading xdebug.so: xdebug.so: cannot open shared object file: No such f

Re: About install the xdebug.

On Mon, 2010-07-12 at 15:30 +0800, peter.zhang wrote: > when I restart the apache , I get the error logs as follow: This mailing list is for bugs in the GNU make program. Your issue is not related. Please try to find a mailing list that deals with either Apache or Xdebug. --

Re: GNU make 3.81.90 prerelease available

On Mon, 2010-07-12 at 10:20 +0300, Eli Zaretskii wrote: > > This change: > > > > 2009-10-03 Paul Smith > > > > * make.h: Include even on systems where __GNUC__ is > > defined. Not sure why it was done the other way. > > Requested by David Boyce . > > > > Causes m

Re: GNU make 3.81.90 prerelease available

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 12 Jul 2010 09:19:42 -0400 > > On Mon, 2010-07-12 at 10:20 +0300, Eli Zaretskii wrote: > > > This change: > > > > > > 2009-10-03 Paul Smith > > > > > > * make.h: Include even on systems where __GNUC__ is > > > defined.

Re: GNU make 3.81.90 prerelease available

>> > > char *alloca (); >> Is this the right return type though? Wouldn't it be void*? > I have no idea. You will see that I didn't touch that line in the > patch, precisely because I don't know what is correct and for which > platform(s). In GNU/Linux's gcc/glibc, it is indeed void*, but it'

[bug #17381] Compile errors under DJGPP

Update of bug #17381 (project make): Assigned to:None => eliz ___ Follow-up Comment #2: Eli: I don't see this patch in the current CVS version. Is this still needed? Thanks! _

[bug #27590] MSVC Win64 build patch

Update of bug #27590 (project make): Assigned to:None => eliz ___ Follow-up Comment #3: Hi Eli; do you have any thoughts on this change? Is this something we should take? _

[bug #24513] make check failure on AIX 5.3

Update of bug #24513 (project make): Status:None => Works for me Open/Closed:Open => Closed ___ Follow-up Comment #2: No response here so I

[bug #25713] Please note CPPFLAGS required to build on Tru64

Follow-up Comment #1, bug #25713 (project make): I'm not sure the best way to handle this. What's the triplet printed by running "config.guess" on your system? ___ Reply to this item at: _

[bug #26921] line 0: unexpected EOF while looking for matching `"'

Update of bug #26921 (project make): Open/Closed:Open => Closed ___ Follow-up Comment #2: No response so I'm marking this closed. Please add a comment if you still see this and I can reop

[bug #26891] make enters interactive shell

Update of bug #26891 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: In 3.82 we have .SHEL

[bug #17381] Compile errors under DJGPP

Update of bug #17381 (project make): Open/Closed:Open => Closed Operating System: MS Windows => MS-DOS ___ Follow-up Comment #3: The MS-DOS build does

[bug #27590] MSVC Win64 build patch

Follow-up Comment #4, bug #27590 (project make): I don't care about the MSVC compiler, I use only GCC. Go ahead and commit this, and if it breaks the GCC build, I will handle it in the next RC. ___ Reply to this item at:

[bug #17381] Compile errors under DJGPP

Update of bug #17381 (project make): Status:None => Fixed Fixed Release:None => CVS ___ Reply to this item at:

[bug #27590] MSVC Win64 build patch

Update of bug #27590 (project make): Status:None => Fixed Assigned to:eliz => psmith Open/Closed:Open => Closed Fixed Release:

[bug #25713] Please note CPPFLAGS required to build on Tru64

Follow-up Comment #2, bug #25713 (project make): config.guess returns "alphaev56-dec-osf4.0g". I would add checks for the missing functions to the configure script, and if not have logic that automatically tries the feature test macros in case the functions aren't found, then at least a note ale

[bug #25713] Please note CPPFLAGS required to build on Tru64

Follow-up Comment #3, bug #25713 (project make): A log would be helpful. The problem is that from what you say, it's not that functions are missing. It seems more like there are errors in the system headers; for example if u_long is not available when compiling getloadavg.c then why not? I can

[bug #25713] Please note CPPFLAGS required to build on Tru64

Follow-up Comment #4, bug #25713 (project make): Okay, I pulled down make-3.81.90 and built on the Tru64 system without setting any flags. It looks like only one file is failing now, albeit with a similar error to what I saw before. Here's the output from a second pass of "make -i": make all-re

[bug #25713] Please note CPPFLAGS required to build on Tru64

Follow-up Comment #5, bug #25713 (project make): Hm, that's interesting. Can you check the status of HAVE_BSD_SIGNAL and HAVE_SIGACTION in config.h? Attaching it would be very helpful. Can you check your system to see if there's a man page for bsd_signal() and if so, what it says the calling a

[bug #25713] Please note CPPFLAGS required to build on Tru64

Follow-up Comment #6, bug #25713 (project make): I'm attaching a copy of config.h, the bsd_signal() man page, and the preprocessed form of main.c. (I'm using the vendor's compiler, so it's just straight "cc -E", but hopefully that'll show what you need.) Relevant tidbits: #define HAVE_BSD_SI