[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build failure on OSX 10.9

From: John W. Eaton
Subject: Re: build failure on OSX 10.9
Date: Fri, 15 Nov 2013 22:02:55 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9

On 11/15/2013 06:51 PM, Ben Abbott wrote:

On Nov 15, 2013, at 3:47 PM, John W. Eaton wrote:

On 11/15/2013 08:59 AM, Ben Abbott wrote:
On Nov 15, 2013, at 8:40 AM, c. wrote:

On 15 Nov 2013, at 14:10, Ben Abbott <address@hidden> wrote:

Ok. I'm still using 2.4, which does not have the qscilexeroctave.h file.

Did I understand correctly that you're able to build by *only* removing the 
"external C++" declaration? ... i.e. no change to libgui/src/module.mk?

yes. either of the two changes will work for me, I don't need both.

Ok.  Any idea why both libgnu/stdio.h and /usr/include/stdio.h are being 

Because that's the way gnulib works.  libgnu/stdio.h first does an
'#include_next <stdio.h>' and then adds its own declarations on top of
the ones that the system provides.

The line in libgnu/stdio.h that triggers the error is the one beginning with 

/* It is very rare that the developer ever has full control of stdin,
    so any use of gets warrants an unconditional warning; besides, C11
    removed it.  */
#undef gets
//_GL_WARN_ON_USE (gets, "gets is a security hole - use fgets instead");

With that commented out, I'm able to build.

I assume this conflict indicates a bug in gnulib?

I think it's a bug in the header file that includes stdio.h inside an extern "C++" block.

What happens if you undo your local changes and apply the attached patch? Does that also avoid the problem?


Attachment: diffs.txt
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]