graphviz for clang*

[revelator]

graphviz-packages.zip

bare bones graphviz packages for clang*.
one small bug remains which means clangs windres cannot be used for building them yet, lefty seems to have a bug in it's resource file causing clangs windres to throw an invalid language id error, it builds cleanly with clang if i use windres from binutils but also means it will be indigestable for a ci build. You can use these untill i find a workaround for the language id bug.

[Biswa96]

You can use these untill i find a workaround for the language id bug

The language id can be passed as integer in base 10 (i.e. 1033) instead of hex. I have tried it. But graphviz failed to build with ucrt, need to relocate path. I have been talking with upstream recently.

[revelator]

would seem so :)

[revelator]

in graphviz case it is 0x409

[jeremyd2019]

https://bugs.llvm.org/show_bug.cgi?id=51295

[jeremyd2019]

https://reviews.llvm.org/D107263. It turns out the language id is always interpreted as hex even without a leading 0x, so it would be -l 409 not -l 1033

[revelator]

ah ok i though it was because it only accepted decimal, well easy fix untill they get it fixed upstream :)

[revelator]

so should be ->

if RC_IS_RC
lefty.res : ws/mswin32/lefty.rc
	rc -l 1003 -Iws/mswin32 '-IC:\\progra~1\\microsoft visual studio 8\\vc\\PlatformSDK\\include' -DNDEBUG -fo lefty.res ws/mswin32/lefty.rc
else
lefty.res : ws/mswin32/lefty.rc
	$(RC) -l 1003 -I$(top_srcdir)/cmd/lefty/ws/mswin32 -DNDEBUG -Ocoff -o lefty.res $(top_srcdir)/cmd/lefty/ws/mswin32/lefty.rc
endif

[revelator]

mingw-w64-graphviz.zip

fixed windres error so should work with clang now :)

[jeremyd2019]

I tried to use this to test the fix to llvm-windres, but it depends on libglade, which is not yet built because that makedepends on python2. It only needs python for a single script libglade-convert, and it looks like it would mostly work on python3. I'm inclined to add a call to 2to3 to the PKGBUILD and switching the dependency over to python.

[revelator]

hmm cannot remember precisely what i did but libglade works just fine with python3 :)

[jeremyd2019]

yeah it's just this one script, and it builds fine with python3, or indeed with no python at all, just the script won't work if something tries to use it.

[revelator]

here you go i used this patch from opensuse leap :)
libglade2-python3.zip

[jeremyd2019]

yeah those are the same changes that 2to3 makes 😉

[revelator]

hehe ;)

[revelator]

btw need to build with -j1 or clang will bork because of a race condition.

[revelator]

one small problem i noticed is that libglade-convert has indentation errors which python2 accepted but python3 does not.
luckily it seems it does not affect building the few things that rely on it :)

[jeremyd2019]

saw that - #9304

[revelator]

just need to point the python in PKGBUILD to python3 instead of python2 and things will work.

[jeremyd2019]

Added my version of graphviz fixes to #9304 since they depend on libglade, so CI can build both.

[jeremyd2019]

forgot that graphviz depends on the updated clang that isn't merged yet. 🤦

[jeremyd2019]

It looks like graphviz is embedding absolute paths on the build machine via -D C preprocessor defines. This is causing an error on UCRT because they were not properly escaping the backslashes and \ucrt isn't a valid unicode escape. But the bigger problem is that these paths will not necessarily be the same on user installs.

[revelator]

makes sense since the fist graphviz mingw port was actually done on msys/mingw i remember it was hell to build though xD

[jeremyd2019]

Well I'm planning to just swap the backslashes with forward slashes (I started out trying to escape the backslashes, but I couldn't find the proper number of backslashes to make it through). If somebody cares enough, this would be a good place to pull in pathtools and get the path relative to the exe.

[revelator]

that should work :)

[jeremyd2019]

argh, it's apparently the msys command line conversion stuff. the path going into the compiler is unixy. I'm going to punt it for now and just remove the define from the makefile. In the .c file if it's not defined it's defined to "." (rather than ".;D:\a\_temp\msys\msys64\clang64\share\graphviz\gvpr" which won't be valid anywhere other than the builder anyway)

[revelator]

hmm seems having imagemagick breaks the swig plugins, if enabled it puts a load of garbadge into the PYTHON2 variable of all things Oo

[jeremyd2019]

#9305