Bug 427376 - RFE graphviz-2.18 - gcc-4.3.0 fixes - tcl-8.5 fixes
RFE graphviz-2.18 - gcc-4.3.0 fixes - tcl-8.5 fixes
Status: CLOSED DUPLICATE of bug 436872
Product: Fedora
Classification: Fedora
Component: graphviz (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Jima
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-01-03 11:36 EST by John Ellson
Modified: 2008-03-10 16:48 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-10 16:48:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
backported fixes for gcc43 build of graphviz-2.16 on fc9 (930 bytes, patch)
2008-02-11 13:54 EST, John Ellson
no flags Details | Diff

  None (edit)
Description John Ellson 2008-01-03 11:36:55 EST
Description of problem:
This is basically just an FYI to jima that I'm working upstream on fixes for
gcc-4.3.0 and for tcl-8.5.   Hope to have new graphviz-2.18 available in a day
or so.  

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Jima 2008-01-03 14:14:25 EST
Muchly appreciated.  I was banging my head on it this morning to no avail. :-)
Comment 2 John Ellson 2008-01-03 21:34:41 EST
There are now some graphviz*2.17.20080104.0129-1.fc9.*.rpm (or later) on
http://www.graphviz.org/ which you can consider as release-candidate for a
graphviz-2.18 release.   These rpm have been built with gcc-4.3.0-0.4 (from koji)
and with tcl-8.5.

Would you please review the new file layout for the binary extensions in
graphviz-tcl, also in graphviz-perl, graphviz-python, graphviz-ruby.

I think I can do the same for graphviz-php before release, but I've not found
the guidelines yet for the other 6 language bindings, so they are less likely to
get moved before release.
Comment 3 Jima 2008-02-01 10:06:26 EST

 Sorry for the delays; the dist-f9-gcc43 tag in Koji had broken dependencies for
quite a while, and dist-f9 didn't have gcc 4.3.0 until the other day.  On
Wednesday I kicked off a scratch build of
graphviz-2.17.20080124.1303-2.fc9.src.rpm, which was slightly modified from the
original in that I BR'd R-devel instead of R; I seem to recall it failed to
properly build the R support the way it was.

Here's the task for that scratch build:


If I'm understanding the TCL guideline draft correctly, we should be putting the
TCL files in %{_libdir}/tcl8.x/, as other paths (such as %{_libdir}/*) may be
getting dropped at some undisclosed point.  See "Extensions," specifically
"arch-specific packages" at:


I'm a bit concerned with the python package; I see the gv.pyc and gv.pyo files
in /usr/lib64/graphviz/python/, but only gv.py in
/usr/lib64/python2.5/site-packages/ -- shouldn't the .pyc/.pyo files appear
there, too?  Mind, I'm not even remotely talented with python; that's just
something I'm used to seeing.

Maybe I don't know enough about how they should be laid out, but I don't see
anything wrong with the way you did the perl or ruby packages. :-)

Again, I apologize for the slowness in triaging this bug; dist-f9-gcc43 hasn't
seemed to be internally consistent since before you made the gcc 4.3.x changes.
Comment 4 John Ellson 2008-02-01 14:17:36 EST

No problem, don't feel rushed by me, we tend to work a lot slower than you
Fedora folks :)

I fixed the BR for R-devel in CVS.  Thx.

In the latest snapshots, there is a /usr/lib64/tcl8.*/graphviz-2.*/ softlink
directory installed under %{_libdir}/tcl8.x/ . I believe this conforms to the
guidelines.  It certainly speeds up tcl scripts using the plugin :)

I'm leaving all the extensions primarily installed under
%{_libdir}/graphviz/<lang>/ then adding softlinks to that from the <lang>s'
preferred locations.   (My reason for this is to make is easier to develop with 
./configure --prefix=$HOME/writable_prefix/  without needing root priviledges
to install all the time.  The softlinks only get installed when run with full
installation priviledges.   Its basically a convenience for us developers.)

So in the case of tcl, graphviz is visible currently in two places, but when you
drop the %{_libdir}-wide search it will only be in one.

I don't understand who/why creates gv.py[oc] either.  Its almost as if rpmbuild
creates them?   The /usr/lib64/python2.5/site-packages/gv.py is just a softlink,
so perhaps its sufficient to have the gv.py[oc] next to the real gv.py only?
Running: /usr/share/graphviz/demo/modgraph.py seems ok without them.

If you have anything to do with the LSB, or with meta discussions on the various
languages in Fedora, there is a couple of things I'd like to see for all languages:
   1. Use pkg-config to indicate extension_lib and extension_share directories.
   2. Always allow lib and share extensions in subdirs under those directories.
Ours is not the only package trying to use SWIG to support 10+ extension
languages.   A little more uniformity could save a lot of effort.

I've been using locally installed gcc-4.3 since the first heads-up, and last
night's snapshots were built using gcc from rawhide, I believe that the latest
graphviz snapshots are going to be fine with it.  One day I'll have to put on my
Janitor hat and try to clean up all the new warnings. :(

Let me know what your schedule pressures are, please?  I could push out a
graphviz-2.18 at just about any time, but right now we have a rather nice large
graph viewer (smyrna) going into the tree that could use a little soaking.

Comment 5 Jima 2008-02-01 14:40:31 EST
Aha.  Okay, if that symlink works for TCL, then that ought to be suitable.

Yes, rpmbuild create the .pyc/.pyo files at build time.  I didn't notice
/usr/lib64/python2.5/site-packages/gv.py was a symlink; what creates that?  The
Makefile?  Well, I'm not certain they're necessary in that tree, at any rate.

I don't have anything to do with LSB.  I don't think anyone wants me having
anything to do with LSB. ;-)  I'm also not really a programmer, which ought to
explain why I defer to upstream's opinion and insight so often.  It's also why I
tend to shy away from policy discussions surrounding language support.  I can't
cook, so I stay out of the kitchen. :-)

I couldn't care less about compiler warnings, as long as things work.  And if
they don't, I'm going to go into hiding.

The only scheduling limit I'm aware of is feature freeze, which is slated for


And even then, it's another month until development freeze.  (Not that I'd
prefer to wait that long, but in case anything goes *too* badly...)  Will that
be a problem?
Comment 6 John Ellson 2008-02-01 20:07:21 EST
Symlinks are created by tclpkg/Makefile.am in the install-data-hook:

You know what happens to chickens in the kitchen?

We might have a 2.20 by then...  no problem.


Comment 7 John Ellson 2008-02-11 13:54:14 EST
Created attachment 294590 [details]
backported fixes for gcc43 build of graphviz-2.16 on fc9

gcc-4.3 fixes for gcc43 build of graphviz-2.16 on fc9

hope this helps
Comment 8 Jima 2008-03-05 09:35:56 EST
These fixes are in graphviz-2.16.1-0.4.fc9, which hit Rawhide yesterday.

I'm not sure if we can get 2.18 into F9...beta freeze got pushed back a week,
but that's a little slim (and I'm going to be out of the office starting tomorrow).
Comment 9 John Ellson 2008-03-10 16:48:31 EDT
Hopefully I'm not too late...   graphviz-2.18 is released.

See BZ#436872

*** This bug has been marked as a duplicate of 436872 ***

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