Bug 241123

Comment 1 Dirk Meyer 2019-10-08 07:18:18 UTC

The go plugin should not be active.
I will fix the options.

quick fix:
CONFIGURE_ARGS+= --disable-python2 --disable-python3 --disable-go

Comment 2 commit-hook 2019-10-08 19:35:10 UTC

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

Comment 3 Dirk Meyer 2019-10-08 19:37:08 UTC

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)

Comment 9 Dirk Meyer 2019-10-10 13:50:40 UTC

(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.

Comment 11 Dirk Meyer 2020-01-03 18:55:42 UTC

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.