check-plist is reporting the following: ===> Checking for items in STAGEDIR missing from pkg-plist Error: Orphaned: lib/graphviz/go/gv.go Error: Orphaned: lib/graphviz/go/libgv_go.la Error: Orphaned: lib/graphviz/go/libgv_go.so Error: Orphaned: lib/graphviz/go/runtime.h Error: Orphaned: lib/graphviz/python2/_gv.so Error: Orphaned: lib/graphviz/python2/gv.py Error: Orphaned: lib/graphviz/python2/libgv_python2.la Error: Orphaned: lib/graphviz/python2/libgv_python2.so Error: Orphaned: lib/graphviz/python3/_gv.so Error: Orphaned: lib/graphviz/python3/gv.py Error: Orphaned: lib/graphviz/python3/libgv_python3.la Error: Orphaned: lib/graphviz/python3/libgv_python3.so Error: Orphaned: lib/python3.6/site-packages/_gv.so Error: Orphaned: lib/python3.6/site-packages/gv.py Error: Orphaned: man/man3/gv.3go.gz Error: Orphaned: %%PORTDOCS%%%%DOCSDIR%%/pdf/gv.3go.pdf ... with these options which, instead of the default options, have POPPLER on, PYTHON on, and NVTHREADS off. ===> The following configuration options are available for graphviz-2.42.2_2: XPM=on: XPM pixmap image format support DIGCOLA=on: neato layout engine with DIGCOLA features IPSEPCOLA=on: neato layout engine with IPSEPCOLA features ICONV=on: Encoding conversion support via iconv NLS=on: Native Language Support PANGOCAIRO=on: pangocairo support POPPLER=on: PDF and PS file support via poppler ANN=off: ANN edge bundling support GTS=off: GNU Triangulated Surface Library support GTK2=off: gtk2 plugin (requires PANGOCAIRO) GDK=off: gdk library support (requires GTK2) GDK_PIXBUF=off: gdk pixbuf support (requires GDK) GNOMEUI=off: libgnomeui support SMYRNA=off: SMYRNA graph viewer (requires GTK2) DEVIL=off: devil plugin GHOSTSCRIPT=off: ghostscript plugin (requires PANGOCAIRO) PERL=off: Perl bindings (swig) PHP=off: PHP bindings (swig) PYTHON=on: Python bindings (swig) RUBY=off: Ruby bindings (swig) LUA=off: Lua bindings (swig) TCL=off: TCL bindings (swig) TK=off: TK toolkit support GUILE=off: Guile bindings (swig) NVTHREADS=off: Link with threads (needed for nvidia) DOCS=on: Build and/or install documentation EXAMPLES=on: Build and/or install examples
The go plugin should not be active. I will fix the options. quick fix: CONFIGURE_ARGS+= --disable-python2 --disable-python3 --disable-go
A commit references this bug: Author: dinoex Date: Tue Oct 8 19:35:04 UTC 2019 New revision: 514099 URL: https://svnweb.freebsd.org/changeset/ports/514099 Log: - new option GO - fix option PYTHON PR: 241123 Changes: head/graphics/graphviz/Makefile head/graphics/graphviz/files/patch-configure.ac head/graphics/graphviz/pkg-plist
merge-quarterly not needed here, the resulting package did not change.
Thanks. I had a similar patch. One thing: python should be a run-time dependency. The _gv.so links with libpython (per ldd).
Also: ===> Checking for items in pkg-plist which are not in STAGEDIR Error: Missing: man/man3/gv.3go.gz Fixed by: --- pkg-plist (revision 514134) +++ pkg-plist (working copy) @@ -278,6 +278,7 @@ man/man3/cdt.3.gz man/man3/cgraph.3.gz man/man3/expr.3.gz +%%GO%% man/man3/gv.3go.gz %%TCL%%man/man3/gdtclft.3tcl.gz %%GO%%man/man3/gv.3go.gz %%GUILE%%man/man3/gv.3guile.gz
Never mind (ignore comment 5). My error. Comment 4 still applies. One additional point. I'm not sure it's ready for python3. (1) configure failure: checking for python... /usr/local/bin/python3.6 File "<string>", line 1 import sys; print sys.prefix (putting parens around sys.prefix would fix that for either py2 or py3) (2) run-time failure using python3: % env PYTHONPATH=/usr/local/lib/graphviz/python/ python3 -c 'import gv' Traceback (most recent call last): File "/usr/local/lib/graphviz/python/gv.py", line 14, in swig_import_helper return importlib.import_module(mname) File "/usr/local/lib/python3.6/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 994, in _gcd_import File "<frozen importlib._bootstrap>", line 971, in _find_and_load File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 658, in _load_unlocked File "<frozen importlib._bootstrap>", line 571, in module_from_spec File "<frozen importlib._bootstrap_external>", line 922, in create_module File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed ImportError: /usr/local/lib/graphviz/python/_gv.so: Undefined symbol "PyInstance_Type" During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/local/lib/graphviz/python/gv.py", line 17, in <module> _gv = swig_import_helper() File "/usr/local/lib/graphviz/python/gv.py", line 16, in swig_import_helper return importlib.import_module('_gv') File "/usr/local/lib/python3.6/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) ImportError: /usr/local/lib/graphviz/python/_gv.so: Undefined symbol "PyInstance_Type" And with python2: % env PYTHONPATH=/usr/local/lib/graphviz/python/ python2 -c 'import gv' && echo ok ok
(In reply to John Hein from comment #6) Sigh. Ignore case (2) (run-time error) above, too. That was compiled with python2 and executed with python3. When compiled with python3 and run with python3, the import works fine.
Ok, one real problem (noticed on 11.x/amd64): /usr/local/lib/graphviz/libgvplugin_xlib.so.6: Undefined symbol "inotify_init" This is a separate bug (I probably should have opened a new one). It looks like libgvplugin_xlib.so is not getting linked with libinotify. I think this happens if devel/libinotify is installed and configure detects the presence of sys/inotify.h: checking sys/inotify.h usability... yes checking sys/inotify.h presence... yes checking for sys/inotify.h... yes This causes HAVE_SYS_INOTIFY_H to be defined and conditional code in plugin/xlib/gvdevice_xlib.c is turned on. But the Makefile does not add -linotify to the build (probably because inotify* symbols are in glibc on linux). configure should be smarter and verify that the symbol is available before turning on inotify code. Workarounds: (1) disable inotify features: (e.g., CONFIGURE_ENV=ac_cv_header_sys_inotify_h=no) (2) if inotify is present, add -linotify to plugin/xlib/Makefile or just globally to LDFLAGS (a) if so, add inotify to LIB_DEPENDS (maybe OPTIONally) % nm -oCD /usr/local/lib/graphviz/libgvplugin_xlib.so.6 | grep inotify /usr/local/lib/graphviz/libgvplugin_xlib.so.6: U inotify_add_watch /usr/local/lib/graphviz/libgvplugin_xlib.so.6: U inotify_init /usr/local/lib/graphviz/libgvplugin_xlib.so.6: U inotify_rm_watch % ldd /usr/local/lib/graphviz/libgvplugin_xlib.so.6 /usr/local/lib/graphviz/libgvplugin_xlib.so.6: libpangocairo-1.0.so.0 => /usr/local/lib/libpangocairo-1.0.so.0 (0x801204000) libpango-1.0.so.0 => /usr/local/lib/libpango-1.0.so.0 (0x801412000) libgobject-2.0.so.0 => /usr/local/lib/libgobject-2.0.so.0 (0x801661000) libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x8018ad000) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x801bc7000) libcairo.so.2 => /usr/local/lib/libcairo.so.2 (0x801dd2000) libthr.so.3 => /lib/libthr.so.3 (0x802104000) libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x80232d000) libX11.so.6 => /usr/local/lib/libX11.so.6 (0x802536000) libm.so.5 => /lib/libm.so.5 (0x80287d000) libc.so.7 => /lib/libc.so.7 (0x800825000) libpangoft2-1.0.so.0 => /usr/local/lib/libpangoft2-1.0.so.0 (0x802aad000) libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0x802cc3000) libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x802f0b000) libfribidi.so.0 => /usr/local/lib/libfribidi.so.0 (0x8031ca000) libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x8033e0000) libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x8036db000) libffi.so.6 => /usr/local/lib/libffi.so.6 (0x80397b000) libpixman-1.so.0 => /usr/local/lib/libpixman-1.so.0 (0x803b82000) libEGL.so.1 => /usr/local/lib/libEGL-NVIDIA.so.1 (0x803e48000) libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x804116000) libxcb-shm.so.0 => /usr/local/lib/libxcb-shm.so.0 (0x804351000) libxcb.so.1 => /usr/local/lib/libxcb.so.1 (0x804553000) libxcb-render.so.0 => /usr/local/lib/libxcb-render.so.0 (0x804779000) libXext.so.6 => /usr/local/lib/libXext.so.6 (0x804986000) libz.so.6 => /lib/libz.so.6 (0x804b97000) libGL.so.1 => /usr/local/lib/libGL-NVIDIA.so.1 (0x804db0000) libharfbuzz.so.0 => /usr/local/lib/libharfbuzz.so.0 (0x8050d4000) libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x8053ae000) libbz2.so.4 => /usr/lib/libbz2.so.4 (0x8055d8000) librt.so.1 => /usr/lib/librt.so.1 (0x8057eb000) libnvidia-glsi.so.1 => /usr/local/lib/libnvidia-glsi.so.1 (0x8059f1000) libXau.so.6 => /usr/local/lib/libXau.so.6 (0x805c7d000) libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x805e80000) libnvidia-tls.so.1 => /usr/local/lib/libnvidia-tls.so.1 (0x806085000) libnvidia-glcore.so.1 => /usr/local/lib/libnvidia-glcore.so.1 (0x806400000) libgraphite2.so.3 => /usr/local/lib/libgraphite2.so.3 (0x807eb4000) libc++.so.1 => /usr/lib/libc++.so.1 (0x8080de000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x8083ad000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8085cc000)
(In reply to John Hein from comment #6) This was already been fixed in: graphics/graphviz/files/patch-configure.ac FreeBSD uses strange include path: make -V PYTHON_INCLUDEDIR /usr/local/include/python3.6m graphviz detected only dirs without 'm'
Note: There was a commit that changed this port that was related to this bug (workaround #1 in comment 8 was committed). The change was committed in ports/r521771, but this was _probably_ an inadvertent commit that should have just been restricted to devel/gperf changes. Dirk may be able to comment about that.
the commits were intended. due a local svn crash the cwd changed and all was commited in one go.
(In reply to Dirk Meyer from comment #11) Well, the commit message for ports r521771 describes nothing about the changes to any of the ports other than gperf (and you have to guess that the "update to 3.1" is solely about gperf and has nothing to do with the other changes that were committed). It looks like most of the commits were some sort of re-ordering of USES to be no longer sorted alphabetically for some reason. And the graphviz change is a real change that affects the inotify issues described here in comment 8 - but nothing in the commit message describes why the change was made. I don't see why a local svn problem means that such a commit is required nor should have been intentional. There are ways to clean up your local working repository without resorting to pushing out bad commits. I suggest reverting the changes that were not part of the actual gperf update. Then if you really want them, make a correct commit that describes what the change is and why.