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): graphviz-2.18 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Muchly appreciated. I was banging my head on it this morning to no avail. :-)
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.
John, 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: http://koji.fedoraproject.org/koji/taskinfo?taskID=384953 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: http://fedoraproject.org/wiki/PackagingDrafts/Tcl 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.
Jima, 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.
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 2008-03-04: http://fedoraproject.org/wiki/Releases/9/Schedule 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?
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. :-)
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
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).
Hopefully I'm not too late... graphviz-2.18 is released. See BZ#436872 *** This bug has been marked as a duplicate of 436872 ***