CMake build does not work on MacOS

This is a duplicate of issue #1456 (closed) which was closed without resolving the underlying issue.

When doing a CMake build on MacOS, the linking stage for gvc produces a lot of linking errors:

Undefined symbols for architecture x86_64:
  "_CL_type", referenced from:
      _graph_init in libcommon.a(input.c.o)
  "_CmdName", referenced from:
      _dotneato_usage in libcommon.a(input.c.o)
      _dotneato_args_initialize in libcommon.a(input.c.o)
  "_Concentrate", referenced from:
      _graph_init in libcommon.a(input.c.o)
  "_E_activefillcolor", referenced from:
      _emit_edge_graphics in libcommon.a(emit.c.o)
  "_E_activepencolor", referenced from:
      _emit_edge_graphics in libcommon.a(emit.c.o)
  "_E_arrowhead", referenced from:
      _graph_init in libcommon.a(input.c.o)
      _arrow_flags in libcommon.a(arrows.c.o)

etc etc… (a complete list of failures can be found in https://pastebin.com/EZnckWYi)

changed the description

One minor problem in the build is that color_lib has to be manually copied, e.g.

$ cp /Users/north/src/graphviz/lib/common/color_lib /Users/north/src/graphviz/build/lib/common/

The real problem is that the graphviz/build/lib/common/CMakeFiles/common.dir/globals.c.o built via cmake does not contain the global symbol definitions needed by graphviz. You can confirm, e.g. nm -Bo | grep Concentrate. It is a mystery why there this does not work. You can run make VERBOSE=1 and see it yourself. Maybe someone that has used cmake a lot can figure this out. Graphviz builds correctly with GNU autotools so I wonder if cmake is generating the wrong code. I don't have time to figure out how to fix cmake. Stephen North

Hi Stephen, thanks for the response.

Bit of background - I've used the same source bundle to successfully build Windows and Linux binaries through CMake - it's only Mac where it doesn't work.

I'm looking to integrate graphviz into our application as an embedded library (cgraph module), which is why CMake is preferred - it gives me control over rpath and/or framework creation on the Mac. I wouldn't know how to accomplish that using autotools. I can confirm that autotools does build correctly on the Mac, but only as a system-installed application. I cannot then turn it into a relocatable library without rewriting all the rpaths afterwards - a rather labour-intensive task...

I'm using the graphviz label stable_release_2.42.2 for my graphviz sources, CMake 3.14.2, MacOS 10.14.5 (Mojave), XCode command-line tools: Apple LLVM version 10.0.1 (clang-1001.0.46.4)

Mark, if you make use of Graphviz on a Mac. Would you please have a look at https://forum.graphviz.org/t/cmake-creates-common-library-as-object-library/500/9?u=vithanco ? Maybe you could provide some input?

I'm afraid that after I got it working once, the project was put on hold and I have not investigated further. Even then, the builds were for a single platform and not targeted at further distribution. I don't really know anything about Macs to be able to give further insight into multi-platform binaries, or even MacOS frameworks.

I notice Fedora has a slightly older clang:

cmake-3.14.5-4.fc31.x86_64 clang-9.0.0-1.fc31.x86_64 llvm-9.0.0-1.fc31.x86_64

I wonder about clang's special sauce for controlling visibility of symbols. https://clang.llvm.org/docs/LTOVisibility.html

Hmm, this missing export of eg _Concentrate, do you think it refer to this?

EXTERN unsigned char Concentrate;	/* if parallel edges should be merged */

from common/globals.h?

Does the Mac build use libtool?

libtool-2.4.6-31.fc31.x86_64

In the automake builds, libcommon is only built as a "convenience" library of .o's (libcommon_C_la), and then later linked into libgvc which is the installable library. This allows for essentially independent Makefiles for lib/common and lib/gvc.

But if the scope of symbols in libcommon is being restricted prematurely then this wont work.

A possible workaround might be for cmake to not compile anything in lib/common, but instead compile lib/common/.c and lib/gvc/.c directly into libgvc

Is LTO visibility a new feature in clang_10 ?

Can anyone try on a Mac with clang_9 ?

Perhaps we need to detect mac builds, and add: attribute((visibility("...")))

like the Windows:

__declspec(dllexport)

I've had the advantage of just trying a brand new / clean install MacOS, and yes I can confirm it needs/uses libtool:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LTDL_INCLUDE_DIR (ADVANCED)
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LTDL_INCLUDE_DIR (ADVANCED)

used by target "gvc"

And yes, I'm getting the exact same linker error, this is with CMake 3.15.4 and AppleClang 11.0.0

The globals.c.o built by cmake does not export global symbols in the way that the automake based compile does. One can determine this just by: $ cd ~/src/graphviz $ nm lib/common/.libs/globals.o | grep N_width 0000000000002c88 S _N_width $ nm build/lib/common/CMakeFiles/common.dir/globals.c.o | grep N_width 0000000000000008 C _N_width $

I don’t think libtool is involved because the compile doesn’t generate a

Here’s how cmake compiles globals.c.o:

[ 22%] Building C object lib/common/CMakeFiles/common.dir/globals.c.o cd /Users/north/src/graphviz/build/lib/common && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -DDIGCOLA -DENABLE_LTDL -DGVC_EXPORTS -DORTHO -DSFDP -D_BLD_gvc=1 -I/Users/north/src/graphviz/build -I/Users/north/src/graphviz/lib/common -I/Users/north/src/graphviz/build/lib/common -I/Users/north/src/graphviz -I/Users/north/src/graphviz/lib/cdt -I/Users/north/src/graphviz/lib/cgraph -I/Users/north/src/graphviz/lib/gvc -I/Users/north/src/graphviz/lib/label -I/Users/north/src/graphviz/lib/pack -I/Users/north/src/graphviz/lib/pathplan -I/Users/north/src/graphviz/lib/fdpgen -I/Users/north/src/graphviz/lib/xdot -fPIC -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -o CMakeFiles/common.dir/globals.c.o -c /Users/north/src/graphviz/lib/common/globals.c

It appears that the automake generated Makefile has -fno-common and adding this to build/lib/common/CMakefiles/common.dir/flags.make allows the build to progress further, but then the compilation of the pango plugin dies: [ 84%] Building C object plugin/pango/CMakeFiles/gvplugin_pango.dir/gvgetfontlist_pango.c.o In file included from /Users/north/src/graphviz/plugin/pango/gvgetfontlist_pango.c:55: In file included from /usr/local/include/pango-1.0/pango/pangocairo.h:25: In file included from /usr/local/include/pango-1.0/pango/pango.h:25: In file included from /usr/local/include/pango-1.0/pango/pango-attributes.h:25: In file included from /usr/local/include/pango-1.0/pango/pango-font.h:25: /usr/local/include/pango-1.0/pango/pango-coverage.h:28:10: fatal error: 'hb.h' file not found #include <hb.h> ^~~~~~ 1 error generated.

which means that the dependency between pango and harfbuzz is not being handled properly in CMake.

Someone with a bigger stake in the CMake build should take a turn at working on this now. Also color_lib needs to be installed (populated into the build tree) in build/lib/common which I assume is just an oversight in some config file somewhere.

Stephen

Great spot on -fno-common, looking at the clang docs this makes complete sense:

-fcommon, -fno-common¶ This flag specifies that variables without initializers get common linkage. It can be disabled with -fno-common.

With this flag added, the cgraph library builds and should hopefully be usable by my application. I shall test that further tomorrow. (I don't build or use the UI components of graphviz)

Also color_lib needs to be installed (populated into the build tree) in build/lib/common which I assume is just an oversight in some config file somewhere.

color_lib is a generated file.

Its included prebuilt in the portable sources because it requires awk to build it.

OK, I also can get the full CMake graphviz build to run, if I

1. manually copy lib/common/color_lib to build/lib/common/color_lib (why doesn't graphviz/cmake/generate_color_lib.cmake.in do this, or is this not being invoked?)
2. manually add -fno-common to C_FLAGS in build/lib/common/CMakeFiles/common.dir/flags.make wherever that really comes from.
3. manually add -I/usr/local/Cellar/harfbuzz/2.6.2/include/harfbuzz to C_INCLUDES in build/plugin/pango/CMakeFiles/gvplugin_pango.dir/flags.make wherever that really comes from (the value should of course come from running pkg-config --cflags harfbuzz).

Please can someone create patches for the CMake configuration to do the above?

I'm no CMake expert, but I think to fix nr 2 you would need to add:

if (APPLE)
   target_compile_options(common PRIVATE "-fno-common")
endif(APPLE)

at the bottom of lib/common/CMakeLists.txt. This should then work for all generators (I typically use Ninja rather than Make)

I tested the CMake change above, and can confirm that I can now build cgraph library and the layout plugins that my application requires. Thank you @truenorth and @ellson for your help.

Please can an expert comment on how to incorporate the proposed patch to lib/common/CMakeLists.txt, which unfortunately "does not work" in the sense that it makes CMake complain,

CMake Error at lib/common/CMakeLists.txt:39 (target_compile_options):
  Cannot specify compile options for target "common" which is not built by
  this project.

I don't think we yet have a resolution to this, but just to document some oddities I found in my travels:

• cmake/generate_color_lib.cmake.in generates some intermediate files that seem unused
• numerous files under cmake/ misspell "uint64_t" as "uint_64_t" when doing string replacement, so I suspect these are accidentally no-ops

I have experienced a similar undefined symbol issue on an older OSX machine (late-2009 Mac Mini, 10.11.6 El Capitan with Xcode 8.2.1/clang 800.0.42.1, CMake 3.17.3). The attached logs are based on the current graphviz source and dependencies supplied by Fink, though I've seen similar behavior with dependencies provided by brew (FWIW, brew doesn't support a platform this old and couldn't successfully build pangocairo but CMake found the minimal graphviz dependencies regardless).

I'm putting together a small MR for changes I made to get CMake to find pangocairo under Fink (glibconfig.h actually) but the only change made for the build using brew dependencies was the addition of set(CMAKE_MACOSX_RPATH TRUE) to the root CMakeLists.txt and even that should have only affected the installation paths, not compilation.

It's old and small and slow but I finally have an OSX machine for testing CMake builds. I've made separate progress building installers and I'd like to take a stab at getting CMake completely working on OSX. Guidance on where to look to sort out this library/symbol issue would be appreciated -- thanks!

cmake_configure.log

cmake_build.log