Bug 1487557

Summary: libjpeg detection fails with gcc7
Product: Red Hat Enterprise Linux 7 Reporter: Miloš Prchlík <mprchlik>
Component: emacsAssignee: Jan Synacek <jsynacek>
Status: CLOSED ERRATA QA Contact: Frantisek Sumsal <fsumsal>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.4CC: fsumsal, mprchlik
Target Milestone: rcKeywords: EasyFix, Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1709832 (view as bug list) Environment:
Last Closed: 2018-10-30 10:45:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1549689    
Attachments:
Description Flags
patch none

Description Miloš Prchlík 2017-09-01 09:18:25 UTC
Description of problem:

Emacs' configure script tries to detect the presence (and version) of libjpeg by grepping output of preprocessor, given this simple C source:

~~~
#include <jpeglib.h>

version=JPEG_LIB_VERSION
~~~

So far, preprocessors were cooperating nicely, giving output like this one (gcc -E <file>):

~~~
...

# 2 "t.c" 2

version=62
~~~

With gcc 7, shipped with Developer Toolset, preprocessor's output slightly changed, splitting the expression to multiple lines:

~~~
...

# 2 "./t.c" 2


# 3 "./t.c"
version=
# 3 "./t.c" 3 4
       62
~~~

This leads to configure printing "WARNING: libjpeg found, but not version 6b or later", and setting HAVE_JPEG=no. Build process then fails with:

configure:12887: error: The following required libraries were not found:
     libjpeg
Maybe some development libraries/packages are missing?
If you don't want to link with them give
     --with-jpeg=no
as options to configure


Version-Release number of selected component (if applicable):

emacs-24.3-19.el7_3
gcc-4.8.5-11.el7.x86_64
devtoolset-7-gcc-7.2.1-1.el7.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Miloš Prchlík 2017-09-11 09:55:54 UTC
I don't know whether it should or shouldn't. Personally, I think it should, at least some day, since gcc-7 is now part of Red Hat's Developer Toolset, but I'm no PM. In this bug, I simply report it's not possible to rebuild Emacs with gcc7. We use "rebuild Emacs" as one of our real-world tests of binutils package, given the complex process of building an Emacs binary, and when testing the new release of Developer Toolset, the build process failed.

Comment 3 Jan Synacek 2017-09-11 10:20:07 UTC
Any chance you could try this with emacs from F26?

Comment 4 Glenn Morris 2017-09-12 22:04:13 UTC
This was changed years ago in the Emacs sources:

http://lists.gnu.org/archive/html/emacs-diffs/2015-03/msg00224.html

(It's changed again since then.)

Comment 5 Jan Synacek 2017-09-13 11:49:52 UTC
Glenn, thanks so much for the pointer! Will the patch that you linked work also with gcc-4.7, or gcc-5+ only? It's kind of hard to say looking at the patch.

Comment 6 Glenn Morris 2017-09-13 17:46:39 UTC
That was the version used in the Emacs 24.5 release, and it works fine with gcc-4 too, as far as I know. The code has changed again since then, but I don't think those changes are relevant to you:

http://lists.gnu.org/archive/html/emacs-diffs/2015-04/msg00258.html

Comment 7 Jan Synacek 2017-09-15 15:32:39 UTC
Created attachment 1326539 [details]
patch

This patch changes configure directly, as we don't run autoconf during the build process. I think that it's still pretty readable.

Comment 8 Glenn Morris 2017-09-16 00:09:10 UTC
It looks to me like you do run autoconf?

http://pkgs.fedoraproject.org/cgit/rpms/emacs.git/tree/emacs.spec#n194

Also, the pre-existing emacs-xwidget.patch patches configure.ac but not configure:

http://pkgs.fedoraproject.org/cgit/rpms/emacs.git/tree/emacs-xwidget.patch#n14

Comment 9 Glenn Morris 2017-09-16 00:14:45 UTC
PS. Oh, sorry: I see the Enterprise spec differs from the Fedora one in this regard.

Comment 16 errata-xmlrpc 2018-10-30 10:45:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3166