Description of problem: arith.h contains: #ifndef INT_MAX #define INT_MAX ((int)(~(unsigned)0 >> 1)) #endif This conflicts with other declarations. See the following code: #include <graphviz/gvc.h> #include <map> int main(int argc, char **argv) { } Suddenly the include order matters here. Compiling the given code with "gcc -o graphvizbug graphvizbug.cpp" leads to the following error: In file included from /usr/include/limits.h:153, from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/limits.h:122, from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/syslimits.h:7, from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/limits.h:11, from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/climits:50, from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_algobase.h:66, from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:66, from /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/map:65, from graphvizbug.cpp:3: /usr/include/bits/xopen_lim.h:95:6: error: missing binary operator before token "(" /usr/include/bits/xopen_lim.h:98:7: error: missing binary operator before token "(" The code in xopen_lim.h compares INT_MAX to a specific integer value (which is included down the road by the inclusion of <map>. Using braces here leads to a syntax error, the braces come from the arith.h INT_MAX declaration. Version-Release number of selected component (if applicable): graphviz-2.12-8.fc7 graphviz-devel-2.12-8.fc7 How reproducible: Always Steps to Reproduce: 1. Put the code mentioned above into a file 2. Try to compile 3. See error message Actual results: Does not compile. Expected results: Should compile without any ordering constraints on the includes. Additional info: graphviz/arith.h should include limits.h for proper definition of INT_MAX etc. and should not define it by itself.
Sorry for the delay in my response. I'm bumping this upstream, as I don't feel this is the kind of change a distro should be making. John, any rationale for this either way?
arith.h will include limits.h if you have HAVE_LIMITS_H defined. e.g. by using a configure.ac test: AC_CHECK_HEADERS(limits.h) I'm willing to listen to better ways of solving this cross-platform problem. This was my solution to compiling on IRIX, SunOS, AIX, HPUX, as well as Linux.
Is there no limits.h on at least one of IRIX, SunOS, AIX, HPUX? As limits.h suggests it is a requirement per "ISO C99 Standard: 7.10/5.2.4.2.1 Sizes of integer types <limits.h>". We are not using autoconf but another build system. This looks like the autoconf tools are a soft dependency for graphviz. Actually it still depends on the include order because if I remember correctly you have to include the generated config.h to get the HAVE_* flags? Maybe it would be an option to define constants like GV_INT_MAX. If HAVE_LIMITS_H is found limits.h is included. Then _LIBC_LIMITS_H_ is checked and if set GV_INT_MAX is defined as INT_MAX, otherwise it is set to the value that you set if INT_MAX is not defined currently. This way there is no conflict and even if HAVE_LIMITS_H is not set it works without conflicts if someone else includes limits.h before or after the arith.h header file.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is still an issue on F-9. John, any comments on my suggestions from comment #3?
I'm trying a change upstream to unconditionally include limits.h and values.h in arith.h. We'll see what this breaks.
Has there been any progress on this issue?
I've forgotten what my conclusion was on this, but it looks as though I made one change. limits.h is now included unconditionally by arith.h before testing #ifndef INT_MAX, so it looks to me like this should work if limit.h is included again either before or after arith.h. If limits.h doesn't exist on SGI's then i don't understand why I haven't heard complaints about this. Could you test with rpms from www.graphviz.org to see if this problem still exists?
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The problem is solved with the current graphviz.org rpms (2.22.2). Are there any plans to include them in Fedora anytime soon? The graphviz packages in Fedora tend to lag behind a long time.
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.