Cmake creates common library as OBJECT library

Dev
#1

It is about the common library and its creation as OBJECT library in Cmake (common_obj) which is then added to a shared library common. However, other Graphviz libraries are depending on common_obj.

I tried to understand why it was done like this and the reason I found were to not compile twice, which reduces compile time and to reduce amount of unused code in resulting files.

On the other side it comes at a cost in complexity in the compile instructions - and prevents macOS universal/fat libraries, i.e. combining arm64 & x86_64 architectures in one file (needed for universal Apps). Creating dependencies on a library declared as OBJECT will lead to Xcode targets that are linked to either the arm64 or x86_64 versions, which in turn will prevent building all libraries depending on libcommon as the linker complains that the other architecture cannot be built.

Now, I have no clue whether creating universal libraries is important as a goal for graphviz in any way and would accept if that is not relevant. I am ultimately happy to work on my own version of graphviz.

What do you think?

#2

Now, I have no clue whether creating universal libraries is important as a goal for graphviz in any way and would accept if that is not relevant.

I’m fine with shipping universal binaries/libraries on macOS. However, an interesting preliminary question is whether Graphviz is even usable on ARM64. Graphviz has many dependencies, some of which I suspect are not yet available for M1 Macs.

#3

It works fine! I was able to create all dependencies as fat binaries. I don’t use pango or gd (what are they for?). The software works fine with static versions of graphviz on my computer. Funnily enough, the arm64 version works better than the x86_64 version. See https://stackoverflow.com/questions/65573639/difference-of-use-of-stack-memory-after-return-between-native-arm64-and-native.

#4

That being said, I fear that OBJECT libraries seem to be non-compatible with fat binaries. So, something might need to give. Should I rather keep that part in my fork?

#5

When I wrote my previous comment, I was thinking Graphviz ships macOS packages. But Stephen’s comment on Gitlab reminded me this is not true. Given this, what are the perceived benefits of building fat binaries? I.e. who are the group of people building macOS Graphviz binaries that they need to be portable across x86-64 and ARM64?

#6

All those that use graphviz in their software and distribute the application through the Apple App Store. There will be a time where both architectures will need to be supported. Intel Mac will still be sold for another 1.5 years, and their expected end of life will be (guesswork) 5 years later. After that, only one architecture might be enough.

#7

Do you have an idea how many people/packages this is? I don’t have much visibility into Apple’s App Store.

#8

of course not. :slight_smile: I have seen a few people in this space over time, but not sure there are many. It might be up to 10.

#9

OK, thanks. I was just trying to gauge how many users/developers we were supporting here and thus how much we should deform the build system to support this use case. AFAIK Homebrew and Macports just package thin binaries for Graphviz right now.

It would be interesting to track down at least one use case for what you describe above to examine their build system and see how they’re currently handling Graphviz. This would give us a better idea of how to integrate and just generally be a better macOS citizen.

#10

I have contacted someone and hope s/he will return regarding other approaches to include graphiv on the Mac. In the meanwhile…

Why do we even have the common library? I found out that cmake uses graphviz for dependency diagrams :slight_smile: So, this is a graph showing all entities with dependency on common_obj.

foo.common
foo.common1279×347 24.8 KB

I don’t think we are loosing a lot if we merge gvc and common - at least for the scope of the current cmake build system. It could be obviously different in the autotools setup.

I guess this is again related to an architecture overview. What is the scope for gvc and common? Does it (still?) make sense to keep them separate?

#11

common was for, well, you know, mostly layout-centric and utilities.

gvc came in later with generalization of job processing (gvc = graphviz context), different semantic layer.

#12

that makes sense. so, most likely we would want to keep it separate.
Would you have a drawing for these “semantic layers”?

#13

From my perspective, it would be acceptable (and possibly even preferable) to ship a monolithic “libgraphviz” containing all layers and algorithms. Fine-grained libraries were once a goal. However, on-disk size is no longer so critical and compiler technologies like LTO have removed most of the downsides to large libraries. Shipping a single library would also let us mitigate code duplication problems like #1868.

#14

Btw, I believe that this is ultimately a CMake issue. I added input to Xcode: Imported object libraries break configuration when building an iOS project (#21276) · Issues · CMake / CMake · GitLab and hope that this is fixing the underlying issue.

#15

Actually, I turned it into a separate issue: Xcode: OBJECT Libraries make dependencies failing for multi-architecture builds (#21796) · Issues · CMake / CMake · GitLab