Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001856graphvizBuild/Installpublic2010-04-15 17:502011-04-28 04:03
ReporterPaulo 
Assigned Togviz 
PrioritynormalSeverityminorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSx86-Other-Windows XP (using cygwOS Version
Summary0001856: comp.lang.c error: initializer element is not constant
Description



Hey guys,
I have tried to build graphviz on cygwin with gcc [ --version reports: (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) ]
and found a problem on file graphviz-2.26.3/lib/gvpr/compile.c at the declaration/definition:
Since I'm compiling for cygwin, WIN32 is not defined, and got error on line 0000083
<CD>
error: initializer element is not constant, both for gprDisc.mem and gprDisc.id attribute members
   80 #ifdef WIN32
   81 static Agdisc_t gprDisc = { 0, 0, &gprIoDisc };
   82 #else
   83 static Agdisc_t gprDisc = { &AgMemDisc, &AgIdDisc, &gprIoDisc };
   84 #endif
</CD>



Seems the problem may be due compiler "should" not know where externals AgMemDisc and AgIdDisc will be placed at compile time
(despite it doesn't yell 'cause of gprIoDisc which is declared on same module), and that would only be determined at link time,
which could be much later if that could be a loadable module...
<CD>
C90 said this in the constraints section of 6.5.7, "Initialization":
C99 says this in the constraints section of 6.7.8, "Initialization":
</CD>



well, the solution given for WIN32 conditional code seems to solve the problem, despite I also
didn't like to have to initialize it everywhere, have found some sugestions such as defining all
global external vars (default static) in a .c module where we may control their order of creation
the disadvantage would be gprDisc would be visible in other modules if they also see the extern
declaration, but no one has said it must be in a header file, only the interested modules that
share these globals need to know about them, externalized on on a header only those that need
to be found everywhere)



Anyway, if the codes guarded with conditionals WIN32 were also compiled the problem would
be already solved, seems to be the only places that happened.
Also would like to suggest if a build version for cygwin could be included on the site.



<CD>
 2452 /* readG:
 2453 * Read graph from file and initialize
 2454 * dynamic data.
 2455 */
 2456 Agraph_t *readG(Sfio_t * fp)
 2457 {
 2458 Agraph_t *g;
 2459
 2460 #ifdef WIN32
 2461 gprDisc.mem = &AgMemDisc;
 2462 gprDisc.id = &AgIdDisc;
 2463 #endif



 ...



 2473 /* openG:
 2474 * Open graph and initialize dynamic data.
 2475 */
 2476 Agraph_t *openG(char *name, Agdesc_t desc)
 2477 {
 2478 Agraph_t *g;
 2479
 2480 #ifdef WIN32
 2481 gprDisc.mem = &AgMemDisc;
 2482 gprDisc.id = &AgIdDisc;
 2483 #endif
</CD>



Additional Information

[erg]
I prefer to keep these strangenesses localized. To me, the ideal solution would use configure to determine if the compilation
system supports addresses of external objects in initializers, and wrap the code with a specific preprocessor variable. Given
that this problem is very limited, the simplest solution would be to replace #ifdef WIN32 with something like #if WIN32 || CYGWIN.
We already use

<CD>
  #if defined(WIN32) && !defined(__MINGW32__) && !defined(__CYGWIN__)
</CD>

several places in the code.

By the way, during some recent clean up, we lost the related mechanism for lt_preloaded_symbols in dot_builtins.c.
This doesn't compile on Windows for the same reason. On Windows, the structure needs to be initialized at runtime.

TagsNo tags attached.
AUXILLARY-FILES
DATE-FIXED
FIX-COMMENT 
So basically on graphviz-2.26.3/lib/gvpr/compile.c if the code with WIN32 conditionals is made default for any plattform
that compiles ok. A better solution could be put all initialization code for globals in a .c module where the order of the creation
FORMER-ID1925
INPUT-FILE
OUTPUT-FILE
STATUS-COMMENT*
VERSION     2.26.3
Attached Files

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2011-04-28 04:03 user1 New Issue
2011-04-28 04:03 user1 Assigned To => user1


MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker