Emacs master build failing on RHEL 6.8

Emacs master build failing on RHEL 6.8

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

Hello,

I am on gcc 7.2.0 on RHEL 6.8, and the emacs build is failing with this
error:

/home/kmodi/stowed/include/m17n-core.h:440:1: warning: function declaration
isn’t a prototype [-Wstrict-prototypes]
 extern MText *mtext ();
 ^~~~~~
  CC       ftxfont.o
  CC       fontset.o
  CC       fringe.o
  CC       image.o
image.c: In function ‘svg_load_image’:
image.c:9468:29: error: missing binary operator before token "("
   #if LIBRSVG_CHECK_VERSION (2, 45, 1) && GNUC_PREREQ (4, 2, 0)
                             ^
make[1]: *** [Makefile:394: image.o] Error 1

Related commit:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=da3897abf1e45741b122b52df37a5cbc68b2ad5d


--
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1217 bytes --]

Re: Emacs master build failing on RHEL 6.8

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 7 May 2019 08:00:16 -0400
> Cc: Paul Eggert <eggert@cs.ucla.edu>
> 
> I am on gcc 7.2.0 on RHEL 6.8, and the emacs build is failing with this
> error:
> 
> /home/kmodi/stowed/include/m17n-core.h:440:1: warning: function declaration
> isn’t a prototype [-Wstrict-prototypes]
>  extern MText *mtext ();
>  ^~~~~~
>   CC       ftxfont.o
>   CC       fontset.o
>   CC       fringe.o
>   CC       image.o
> image.c: In function ‘svg_load_image’:
> image.c:9468:29: error: missing binary operator before token "("
>    #if LIBRSVG_CHECK_VERSION (2, 45, 1) && GNUC_PREREQ (4, 2, 0)
>                              ^
> make[1]: *** [Makefile:394: image.o] Error 1

What version of librsvg do you have there, and what does the
LIBRSVG_CHECK_VERSION macro look like in its headers?

Re: Emacs master build failing on RHEL 6.8

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

On Tue, May 7, 2019 at 10:34 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> What version of librsvg do you have there, and what does the
> LIBRSVG_CHECK_VERSION macro look like in its headers?
>

km²/usr:include/librsvg-2>
pwd                                                              05/07
10:39am
/usr/include/librsvg-2
km²/usr:include/librsvg-2> rg
VERSION                                                       05/07 10:40am
librsvg/librsvg-features.h
4:#define LIBRSVG_MAJOR_VERSION (2)
5:#define LIBRSVG_MINOR_VERSION (26)
6:#define LIBRSVG_MICRO_VERSION (0)
7:#define LIBRSVG_VERSION ""
9:#define LIBRSVG_CHECK_VERSION(major,minor,micro) \
10:  (LIBRSVG_MAJOR_VERSION > (major) || \
11:   (LIBRSVG_MAJOR_VERSION == (major) && LIBRSVG_MINOR_VERSION > (minor))
|| \
12:   (LIBRSVG_MAJOR_VERSION == (major) && LIBRSVG_MINOR_VERSION == (minor)
&& LIBRSVG_MICRO_VERSION >= (micro)))

The version is 2.26.0.

I see " #define LIBRSVG_CHECK_VERSION(major,minor,micro) \" .. note that
there is no space before the opening bracket .. is that detail important?

[-- Attachment #2: Type: text/html, Size: 1649 bytes --]

Re: Emacs master build failing on RHEL 6.8

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 7 May 2019 10:41:55 -0400
> Cc: Paul Eggert <eggert@cs.ucla.edu>, Emacs developers <emacs-devel@gnu.org>
> 
> 4:#define LIBRSVG_MAJOR_VERSION (2)
> 5:#define LIBRSVG_MINOR_VERSION (26)
> 6:#define LIBRSVG_MICRO_VERSION (0)
> 7:#define LIBRSVG_VERSION ""
> 9:#define LIBRSVG_CHECK_VERSION(major,minor,micro) \
> 10:  (LIBRSVG_MAJOR_VERSION > (major) || \
> 11:   (LIBRSVG_MAJOR_VERSION == (major) && LIBRSVG_MINOR_VERSION > (minor))
> || \
> 12:   (LIBRSVG_MAJOR_VERSION == (major) && LIBRSVG_MINOR_VERSION == (minor)
> && LIBRSVG_MICRO_VERSION >= (micro)))
> 
> The version is 2.26.0.

Maybe I'm blind, but I don't see anything wrong here (although
LIBRSVG_VERSION's value looks strange).

Does it help to flush the # characters all the way to the left, and
also to take the conditions in parens?  Like this:

#if GNUC_PREREQ (4, 6, 0)
#pragma GCC diagnostic push
#endif
#if (LIBRSVG_CHECK_VERSION (2, 45, 1)) && (GNUC_PREREQ (4, 2, 0))
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#endif

> I see " #define LIBRSVG_CHECK_VERSION(major,minor,micro) \" .. note that
> there is no space before the opening bracket .. is that detail important?

Yes, and the lack of space in the macro definition is correct.

Re: Emacs master build failing on RHEL 6.8

[Stefan Monnier]

> Does it help to flush the # characters all the way to the left, and

Indeed, I'm surprised by:

  #if GNUC_PREREQ (4, 6, 0)
   #pragma GCC diagnostic push
  #endif
  #if LIBRSVG_CHECK_VERSION (2, 45, 1) && GNUC_PREREQ (4, 2, 0)
   #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
  #endif

I always thought that the `#` at to be in column-0, hence the
indentation convention of:

    #if foo
    #  define BAR toto
    #endif

But since this is coming from Paul, I assume he knows that it's allowed
to have spaces before the `#` (at least in recent enough versions of C?).


        Stefan

Re: Emacs master build failing on RHEL 6.8

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 07 May 2019 11:30:45 -0400
> 
> Indeed, I'm surprised by:
> 
>   #if GNUC_PREREQ (4, 6, 0)
>    #pragma GCC diagnostic push
>   #endif
>   #if LIBRSVG_CHECK_VERSION (2, 45, 1) && GNUC_PREREQ (4, 2, 0)
>    #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
>   #endif
> 
> I always thought that the `#` at to be in column-0, hence the
> indentation convention of:
> 
>     #if foo
>     #  define BAR toto
>     #endif
> 
> But since this is coming from Paul, I assume he knows that it's allowed
> to have spaces before the `#` (at least in recent enough versions of C?).

Moreover, it works for everyone else, evidently, including with
GCC 7.x (which is what I have here).  Something strange goes on there.

Re: Emacs master build failing on RHEL 6.8

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

On Tue, May 7, 2019 at 11:54 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> Moreover, it works for everyone else, evidently, including with
> GCC 7.x (which is what I have here).  Something strange goes on there.
>

I am on gcc 7.2.0.

I tried with/without the extra parens and with/without the # chars in
col-0, but still am getting " error: missing binary operator before token
"("".

[-- Attachment #2: Type: text/html, Size: 753 bytes --]

Re: Emacs master build failing on RHEL 6.8

[martin rudalics]

 > image.c: In function ‘svg_load_image’:
 > image.c:9468:29: error: missing binary operator before token "("
 >     #if LIBRSVG_CHECK_VERSION (2, 45, 1) && GNUC_PREREQ (4, 2, 0)
 >                               ^
 > make[1]: *** [Makefile:394: image.o] Error 1

Could this be because LIBRSVG_CHECK_VERSION is defined in
librsvg-features.h and we include rsvg.h only?

martin

Re: Emacs master build failing on RHEL 6.8

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 7 May 2019 19:37:14 +0200
> Cc: Paul Eggert <eggert@cs.ucla.edu>
> 
>  > image.c: In function ‘svg_load_image’:
>  > image.c:9468:29: error: missing binary operator before token "("
>  >     #if LIBRSVG_CHECK_VERSION (2, 45, 1) && GNUC_PREREQ (4, 2, 0)
>  >                               ^
>  > make[1]: *** [Makefile:394: image.o] Error 1
> 
> Could this be because LIBRSVG_CHECK_VERSION is defined in
> librsvg-features.h and we include rsvg.h only?

That's how this should be done: rsvg.h includes librsvg-features.h, at
least in my librsvg headers.  librsvg-features.h will print a warning
if you include it directly.

Re: Emacs master build failing on RHEL 6.8

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 7 May 2019 12:01:59 -0400
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Emacs developers <emacs-devel@gnu.org>
> 
> I tried with/without the extra parens and with/without the # chars in col-0, but still am getting " error: missing
> binary operator before token "("".

As expected.

Can you show that part from a preprocessed image.c?

Re: Emacs master build failing on RHEL 6.8

[Mattias Engdegård]

7 maj 2019 kl. 17.30 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
> 
> I always thought that the `#` at to be in column-0, hence the
> indentation convention of:
> 
>    #if foo
>    #  define BAR toto
>    #endif
> 
> But since this is coming from Paul, I assume he knows that it's allowed
> to have spaces before the `#` (at least in recent enough versions of C?).

It's always been allowed as far as I know. Perhaps some pre-standard (K&R) preprocessors didn't like it.

It's common in style rules to mandate # at the left margin, but that always looked like superstition (or perverted aesthetics) to me.

Re: Emacs master build failing on RHEL 6.8

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

On Tue, May 7, 2019 at 2:22 PM Eli Zaretskii <eliz@gnu.org> wrote:

>
> Can you show that part from a preprocessed image.c?
>

What's the "preprocessed" image.c? In any case, here's that part of image.c
after reverted all local changes to it so that it's the exact same as on
master:


  /* Suppress GCC deprecation warnings starting in librsvg 2.45.1 for
     rsvg_handle_write and rsvg_handle_close.  FIXME: Use functions
     like rsvg_handle_new_from_gfile_sync on newer librsvg versions,
     and remove this hack.  */
  #if GNUC_PREREQ (4, 6, 0)
   #pragma GCC diagnostic push
  #endif
  #if LIBRSVG_CHECK_VERSION (2, 45, 1) && GNUC_PREREQ (4, 2, 0)
   #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
  #endif

PS: I was able to build emacs locally after commenting out the " #if
LIBRSVG_CHECK_VERSION .. #endif" portion.

[-- Attachment #2: Type: text/html, Size: 1337 bytes --]

Re: Emacs master build failing on RHEL 6.8

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 7 May 2019 15:46:18 -0400
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Emacs developers <emacs-devel@gnu.org>
> 
>  Can you show that part from a preprocessed image.c?
> 
> What's the "preprocessed" image.c?

The way it looks after preprocessing by cpp.  The procedure to produce
that is as follows:

  . Go to src and type "make image.o -W image.c V=1
  . Copy-paste the GCC command that the above displays, but replace -c
    with -E and "-o image.o" with "-o image.ii", then press Enter
  . Posit image.ii here.

Re: Emacs master build failing on RHEL 6.8

[Andreas Schwab]

On Mai 08 2019, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Kaushal Modi <kaushal.modi@gmail.com>
>> Date: Tue, 7 May 2019 15:46:18 -0400
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Emacs developers <emacs-devel@gnu.org>
>> 
>>  Can you show that part from a preprocessed image.c?
>> 
>> What's the "preprocessed" image.c?
>
> The way it looks after preprocessing by cpp.  The procedure to produce
> that is as follows:
>
>   . Go to src and type "make image.o -W image.c V=1

Run "rm image.o; make image.o CFLAGS+=-save-temps" and pick up the file
`image.i'.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Emacs master build failing on RHEL 6.8

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Wed, May 8, 2019 at 1:48 AM Eli Zaretskii <eliz@gnu.org> wrote:

> The way it looks after preprocessing by cpp.  The procedure to produce
> that is as follows:
>
>   . Go to src and type "make image.o -W image.c V=1
>

You might have expected, but when I ran that command, I got the same error:
http://ix.io/1Iog



>   . Copy-paste the GCC command that the above displays, but replace -c
>     with -E and "-o image.o" with "-o image.ii",


I did that, but there was no "-o image.o", so I just redirected the output
to image.ii.


> then press Enter
>   . Posit image.ii here.
>

Here it is:
https://gist.githubusercontent.com/kaushalmodi/ff2b0377a7e7d508247d874295a81c3b/raw/3a93ce939e17d34945ecc1058d7e7ce121fe2c20/image.ii

[-- Attachment #2: Type: text/html, Size: 1674 bytes --]

Re: Emacs master build failing on RHEL 6.8

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Wed, 8 May 2019 07:42:24 -0400
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Emacs developers <emacs-devel@gnu.org>
> 
>    . Go to src and type "make image.o -W image.c V=1
> 
> You might have expected, but when I ran that command, I got the same error: http://ix.io/1Iog

the purpose of that was to show the command, it doesn't matter whether
it succeeds.

>  then press Enter
>    . Posit image.ii here.
> 
> Here it is:
> https://gist.githubusercontent.com/kaushalmodi/ff2b0377a7e7d508247d874295a81c3b/raw/3a93ce939e17d34945ecc1058d7e7ce121fe2c20/image.ii

Thanks, but it looks like only part of the file is there: it ends in
the middle of the source, before it gets to the interesting parts.

Re: Emacs master build failing on RHEL 6.8

[Kaushal Modi]

[-- Attachment #1.1: Type: text/plain, Size: 504 bytes --]

On Wed, May 8, 2019 at 8:27 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> Thanks, but it looks like only part of the file is there: it ends in
> the middle of the source, before it gets to the interesting parts.
>

Oops, looks like gist auto-truncated it because of the size of the file
(and the ix.io service completely rejected that).

I didn't want to attach a huge payload to this mailing list. This time, I
am attaching a ~500kb tar.xz .. let's see if that gets to you.

Thanks for looking into this.

[-- Attachment #1.2: Type: text/html, Size: 907 bytes --]

[-- Attachment #2: image.ii.tar.xz --]
[-- Type: application/octet-stream, Size: 526364 bytes --]

Re: Emacs master build failing on RHEL 6.8

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Wed, 8 May 2019 08:49:05 -0400
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Emacs developers <emacs-devel@gnu.org>
> 
>  Thanks, but it looks like only part of the file is there: it ends in
>  the middle of the source, before it gets to the interesting parts.
> 
> Oops, looks like gist auto-truncated it because of the size of the file (and the ix.io service completely rejected
> that). 
> 
> I didn't want to attach a huge payload to this mailing list. This time, I am attaching a ~500kb tar.xz .. let's see if
> that gets to you.

Thanks, now everything is clear.  Please try the latest master, I
tried to fix this.

Re: Emacs master build failing on RHEL 6.8

[Kaushal Modi]

[-- Attachment #1.1: Type: text/plain, Size: 536 bytes --]

On Wed, May 8, 2019 at 9:05 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> Thanks, now everything is clear.  Please try the latest master, I
> tried to fix this.
>

Sorry, I still get the same error:

image.c: In function ‘svg_load_image’:
image.c:9468:62: error: missing binary operator before token "("
   #if defined LIBRSVG_CHECK_VERSION && LIBRSVG_CHECK_VERSION (2, 45, 1) \
                                                              ^
make: *** [Makefile:394: image.o] Error 1

I've attached the new image.ii.

[-- Attachment #1.2: Type: text/html, Size: 1096 bytes --]

[-- Attachment #2: image.ii.tar.xz --]
[-- Type: application/octet-stream, Size: 526220 bytes --]

Re: Emacs master build failing on RHEL 6.8

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

On 5/8/19 8:07 AM, Kaushal Modi wrote:
>
> image.c:9468:62: error: missing binary operator before token "("
>    #if defined LIBRSVG_CHECK_VERSION && LIBRSVG_CHECK_VERSION (2, 45, 1) \

I installed the attached to try to fix that.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Port-LIBRSVG_CHECK_VERSION-fix-to-picky-cpp.patch --]
[-- Type: text/x-patch; name="0001-Port-LIBRSVG_CHECK_VERSION-fix-to-picky-cpp.patch", Size: 1511 bytes --]

From e8e4ba1fd2b93eed3088791d7cd30048693612e1 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 8 May 2019 08:37:40 -0700
Subject: [PATCH] Port LIBRSVG_CHECK_VERSION fix to picky cpp
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/image.c (LIBRSVG_CHECK_VERSION): Define to yield false
if it isn’t already defined.
(svg_load_image): Port to C preprocessors that check the
syntax of the entire preprocessing expression before
evaluating any of it.
---
 src/image.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/image.c b/src/image.c
index 725eb4b8d0..e8cb434177 100644
--- a/src/image.c
+++ b/src/image.c
@@ -9248,6 +9248,11 @@ svg_image_p (Lisp_Object object)
 
 # include <librsvg/rsvg.h>
 
+/* librsvg is too old for us if it doesn't define this macro.  */
+# ifndef LIBRSVG_CHECK_VERSION
+#  define LIBRSVG_CHECK_VERSION(v, w, x) false
+# endif
+
 # ifdef WINDOWSNT
 
 /* Restore the original definition of __MINGW_MAJOR_VERSION.  */
@@ -9465,8 +9470,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
   #if GNUC_PREREQ (4, 6, 0)
    #pragma GCC diagnostic push
   #endif
-  #if defined LIBRSVG_CHECK_VERSION && LIBRSVG_CHECK_VERSION (2, 45, 1) \
-    && GNUC_PREREQ (4, 2, 0)
+  #if LIBRSVG_CHECK_VERSION (2, 45, 1) && GNUC_PREREQ (4, 2, 0)
    #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
   #endif
 
-- 
2.21.0

Re: Emacs master build failing on RHEL 6.8

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On Wed, May 8, 2019 at 11:41 AM Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 5/8/19 8:07 AM, Kaushal Modi wrote:
> >
> > image.c:9468:62: error: missing binary operator before token "("
> >    #if defined LIBRSVG_CHECK_VERSION && LIBRSVG_CHECK_VERSION (2, 45, 1)
> \
>
> I installed the attached to try to fix that.
>

That worked!

Many thanks to you and Eli to help support the old RHEL 6.8. I remember
seeing the emacs user stats and that reported only 3 users to use RHEL (I
am one of those 3 :D).

[-- Attachment #2: Type: text/html, Size: 873 bytes --]

Re: Emacs master build failing on RHEL 6.8

[Paul Eggert]

On 5/7/19 11:49 AM, Mattias Engdegård wrote:
> It's always been allowed as far as I know. Perhaps some pre-standard (K&R) preprocessors didn't like it.

That's correct. C89-and-later allows white space (but not comments)
before the leading "#" in a line. K&R C did not.


> It's common in style rules to mandate # at the left margin, but that always looked like superstition (or perverted aesthetics) to me.

Yes, that common style is often hard to read. It exists mostly because
of inertia. For example, by default cc-mode insists on jamming the "#"
on the left and I have been too lazy so far to fix that (at least it
should respect the already-existing style).

CPP indentation bikeshed (was: Emacs master build failing on RHEL 6.8)

[Stefan Monnier]

> That's correct. C89-and-later allows white space (but not comments)
> before the leading "#" in a line. K&R C did not.

Aha!  So it comes from K&R!
Thanks.

>> It's common in style rules to mandate # at the left margin, but that
>> always looked like superstition (or perverted aesthetics) to me.
> Yes, that common style is often hard to read. It exists mostly because
> of inertia. For example, by default cc-mode insists on jamming the "#"
> on the left and I have been too lazy so far to fix that (at least it
> should respect the already-existing style).

FWIW, I find indentation such as the chunk below from coding.c:

    if (VECTORP (eol_type))
      {
        /* Format of end-of-line decided by system.
           This is Qunix on Unix and Mac, Qdos on DOS/Windows.
           This has an effect only for external encoding (i.e., for output to
           file and process), not for in-buffer or Lisp string encoding.  */
        Lisp_Object system_eol_type = Qunix;
        #ifdef DOS_NT
         system_eol_type = Qdos;
        #endif

to be philosophically wrong: CPP doesn't know anything about C's
syntactic structure (such as {...} nesting), so its indentation should
only pay attention to previous CPP statement and not surrounding C code.

Basically, the way I see it, you have code from two different languages
(C and CPP) that is interleaved (in completely arbitrary ways, not
always obeying nesting) and indentation of one should not impact
indentation of the other.  E.g. the reverse situation is also something
I wouldn't like:

    #    ifdef FOO
           extern toto ();
    #    else
           extern toto (int x);
    #    endif

As for jamming # to the left: I like to do that probably mostly out of
habit, but I can rationalize it based on the argument that CPP is applied
"outside" of the C execution, so CPP statement and "layed over" the text
of the C source.


        Stefan

Re: CPP indentation bikeshed (was: Emacs master build failing on RHEL 6.8)

[Paul Eggert]

Stefan Monnier wrote:
> CPP doesn't know anything about C's
> syntactic structure (such as {...} nesting)

That's going a bit too far, as cpp does knows about C's comments and about C's 
parentheses and commas. True, cpp pays no special attention to { and }.

My own feeling is that in cases like these, utility trumps philosophical 
consistency. When an '#if' is required but otherwise has the function of a plain 
'if', the code is clearer when indented consistently with plain 'if' as this 
gives the reader a simple and helpful visual cue: an indented "#" means that the 
preprocessor code is following the normal C syntactic structure, whereas an 
unindented "#" means the preprocessor code is unusual and is breaking the normal 
C structure. Always shoving the "#" to the left loses this useful information 
and forces the reader to work harder.

Re: Emacs master build failing on RHEL 6.8

[WilliamKF]

This is still an issue with Emacs-26.3 on RHEL 6.8 and the proposed fix does
not work for me, the preprocessor still continues and gets same error after
&& now.  Workaround is to just comment out the offending portion which is
incorrect but working for me:

    #if defined  LIBRSVG_CHECK_VERSION //&& LIBRSVG_CHECK_VERSION (2, 45, 1) 

Note that LIBRSVG_CHECK_VERSION is not defined for me, so this gives me at
least the correct build.



--
Sent from: http://emacs.1067599.n8.nabble.com/Emacs-Dev-f108916.html

Re: Emacs master build failing on RHEL 6.8

[Paul Eggert]

On 2/14/20 11:49 AM, WilliamKF wrote:
> This is still an issue with Emacs-26.3 on RHEL 6.8 and the proposed fix does
> not work for me

That should be fixed in Emacs 27, as described here:

https://lists.gnu.org/r/emacs-devel/2019-05/msg00210.html

We're not worrying about Emacs 26 these days, but your workaround looks 
OK for it.