Bug 427616 - libjpeg headers define HAVE_STDLIB_H
libjpeg headers define HAVE_STDLIB_H
Product: Fedora
Classification: Fedora
Component: libjpeg (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Tom Lane
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-01-05 08:27 EST by Kevin Kofler
Modified: 2013-07-02 23:16 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-13 15:40:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kevin Kofler 2008-01-05 08:27:37 EST
Description of problem:
The libjpeg header (jpeglib.h) includes jconfig.h which defines HAVE_STDINT_H. 
This causes redefinition errors in kdelibs3, and potentially other packages 
too, with GCC 4.3. (In the kdelibs3 case, there is a workaround (an #undef 
before including jpeglib.h) already in the source code, but the workaround 
doesn't work with --enable-final (it needs a second #undef _after_ including 
it), and this issue is best fixed in libjpeg anyway.)

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

How reproducible:

Steps to Reproduce:
1. Try building kdelibs3 in Rawhide with GCC 4.3.
Actual results:
In file included from arena.cpp:45,
                 from libkhtmlmisc_la.all_cpp.cpp:8:
../../config.h:477:1: error: "HAVE_STDLIB_H" redefined
In file included from /usr/include/jpeglib.h:28,
                 from loader_jpeg.cpp:44,
                 from libkhtmlmisc_la.all_cpp.cpp:4:
/usr/include/jconfig.h:12:1: error: this is the location of the previous 

Expected results:
No error
Comment 1 Kevin Kofler 2008-01-05 08:28:33 EST
Sorry, it's actually HAVE_STDLIB_H (and HAVE_STDDEF_H, though that doesn't 
cause an issue with KDE) which is being defined, not HAVE_STDINT_H.
Comment 2 Tom Lane 2008-01-05 12:18:23 EST
Every autoconf-based package in the world is likely to define that symbol.  I think you probably need to 
have a word with the gcc people about whether this warning is well-advised.
Comment 3 Kevin Kofler 2008-01-05 13:56:52 EST
* They aren't supposed to define those symbols in the public headers though.
* This is not a warning, this is an error in GCC 4.3, so this issue _must_ be 
fixed before GCC 4.3 hits Rawhide. (If you refuse to fix it in libjpeg, I'll 
have to work around it in kdelibs3.)
* The error only triggers if they are defined differently, in this case the 
problem is that libjpeg #defines it to nothing and kdelibs3 to 1. But please 
don't change libjpeg to #define it to 1, as this may break other packages which 
currently work.
Comment 4 Tom Lane 2008-01-05 17:02:58 EST
Well, the alternatives I'm prepared to offer you are to do nothing or to #define it as 1.  I'm not going to 
make large rearrangements in what libjpeg's headers export, because that seems even *more* likely to 
break random clients, and because it's been generally fine as-is for more than ten years now.  However, 
given that autoconf prefers to #define these symbols as 1 rather than empty, I can see the value of 
changing things that much.  It seems implausible that such a change would break anything --- do you 
have any specific cases in mind that would be likely to fail?
Comment 5 Kevin Kofler 2008-01-05 19:13:54 EST
Any existing programs #defining it to nothing will break, I'm not sure there 
are any though. I guess you can give it a try and see what breaks.
Comment 6 Tom Lane 2008-01-06 03:03:26 EST
On looking into it, the main problem is that libjpeg is still using a configure script from autoconf 2.12...

Obviously the real solution is to drop in a more modern script, but it might take a few days to shake that 
out.  How soon do you need a fix?  I could push in a really grotty patch of a few lines in the existing 
script, if you need it right away, but that's not where I want to be in the long run.
Comment 7 Kevin Kofler 2008-01-06 16:15:11 EST
It's not that urgent, Rawhide is still using GCC 4.1 right now, where this was 
just a warning, I don't know when exactly the switch to 4.3 will happen.
Comment 8 Tom Lane 2008-01-13 15:40:50 EST
Done in libjpeg-6b-40, please give it a try.
Comment 9 Nicolas Chauvet (kwizart) 2008-01-14 11:13:03 EST
I have experienced this problem also while testing gcc 4.3.0 and cinelerra
With libjpeg-6b-40 the error is gone...
Thx for have it fixed (and for the reporter).

Note You need to log in before you can comment on or make changes to this bug.