graphviz-gui @2.49.1_0.darwin_15.x86_64: unknown type name 'NSToolbarItemIdentifier'

[thetrial (alabay)]

Graphviz-gui is not building. I’ll attach the logfile.

error: unknown type name 'NSToolbarItemIdentifier'; did you mean 'NSTouchBarItemIdentifier'?

[evanmiller (Evan Miller)]

NSToolbarItemIdentifier is an NSString typedef that was introduced in 10.13: ​https://developer.apple.com/documentation/appkit/nstoolbaritemidentifier?language=objc

There shouldn't be any problem deploying to 10.11, but right now it looks like the code base is assuming a 10.13+ SDK.

The error in question originates from this change:

​https://gitlab.com/graphviz/graphviz/-/commit/544035e049fb38ab4243c5ae225aa48f2ab3b4ac

[mascguy (Christopher Nielsen)]

Interestingly enough, graphviz-gui is only failing to build on one of our buildbots - macOS 10.11:

​https://ports.macports.org/port/graphviz-gui/details/

With the details here, though it looks like it's the same issue:

​https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/155777/steps/install-port/logs/stdio

Ryan/anyone, thoughts as to what the "right" fix for this should be...?

[evanmiller (Evan Miller)]

Try

reinplace "s|NSToolbarItemIdentifier|NSString *|" macosx/GVAttributeInspectorController.h

[mascguy (Christopher Nielsen)]

Replying to evanmiller:

Try

reinplace "s|NSToolbarItemIdentifier|NSString *|" macosx/GVAttributeInspectorController.h

Wow, didn't expect it to be quite that easy! LOL

I'll test this today. Thanks so much Evan!

[evanmiller (Evan Miller)]

@mascguy Did you try it? The regex might need a "g" at the end for a global replacement.

[mascguy (Christopher Nielsen)]

Replying to evanmiller:

@mascguy Did you try it? The regex might need a "g" at the end for a global replacement.

Haven't had a chance to tackle this yet. Presently preoccupied with foundational ports, which are failing to build on some of our buildbots. Which in turn block downstream dependents from being built, etc. Starting to see the light of day though.

However, this is still on my near-term to-do list, as I'd certainly love to eliminate these build failures too!

[thetrial (alabay)]

What happened to this? Is it forgotten or did problems occur?

[thetrial (alabay)]

Nearly a half year ago it sounded like this is a very easy, little thing. Now it’s stuck. I hope it’s not a bigger problem away form technical aspects?!

[mascguy (Christopher Nielsen)]

Sorry folks, had been back-burnering this. I'll try to take a look over the coming days.

[trijezdci (Benjamin Kowarsch)]

Perhaps it is easier to add an older version of Graphviz and Graphviz-Gui to macports?

I have an old MBP13 from 2009 whose last supported OS is 10.11 and its last supported version of Xcode is 8.2. I used to run Graphviz v2.38 on it with an older MacOS but that no longer works on 10.11. When I try to install the latest version (2.50) graphviz-gui fails in the same manner as reported in this ticket.

However, I found blog entries on the internet where people reported using Graphviz 2.40 on 10.11. Unfortunately, I could not find any binary package nor any macports entries for 2.40 so I couldn't try that. It may even be that building 2.38 on OSX 10.11 and Xcode 8.2 (and its associated CLTs) would produce a working build. But unfortunately, there are no macports entries for 2.38 either.

Is it possible that somebody could add graphviz and graphviz-gui version 2.38 or 2.40 ???

Thanks a lot in advance.

[thetrial (alabay)]

Graphviz 2.40.1 had been the version before this via MacPorts.

[mascguy (Christopher Nielsen)]

I'm unable to reproduce this failure locally on 10.11, building with Xcode 7.3.1.

Of note, both the reporter - as well as our 10.11 buildbot - are utilizing Xcode 8.2.1. However, the latter includes the 10.12 SDK, which appears to be the culprit.

Currently pondering what the best way to fix this is. But in the interim, if you switch to Xcode 7.3.1 - which I'd strongly recommend anyway, unless you have any ports that require a 10.12 SDK - that should solve the issue.

[thetrial (alabay)]

I’m really not sure if it would be a good idea to change the xcode version in my systems … after years. I’m sure this would open doors to other problems. But – isn’t it possible to let the build process use a specific compiler or sdk or whatever?

[sambthompson (Sam Thompson)]

Replying to thetrial:

I’m really not sure if it would be a good idea to change the xcode version in my systems … after years. I’m sure this would open doors to other problems. But – isn’t it possible to let the build process use a specific compiler or sdk or whatever?

Agreed. I've been running 8.2.1 pretty much since its release. It shouldn't be necessary to go backwards given the earlier SDK is available and installed (and works happily for a bunch of other ports, including earlier versions of this one).

Given Evan Miller's earlier comment about the introduction of the symbol in the 10.13 SDK, going back to 10.11 SDK won't address, surely, unless the port's code base has an issue whereby it expects the symbol in the 10.12 SDK, instead of 10.13, but not in 10.11. Is it then an upstream fix, or can the 10.11 SDK be forced?

Followup questions: Given the NSToolbarItemIdentifier type is referenced seemingly without an #ifdef or other SDK version guard, why does this build successfully on 10.12, or 10.10 and earlier? How is that even possible, and is it a clue to how to fix?

[mascguy (Christopher Nielsen)]

I have a fix which I'm comfortable with, and will be merging shortly. The most time-consuming part is installing Xcode 8.2.1, so that it can be properly tested.

[Christopher Nielsen <mascguy@…>]

In ecb41cddf54ad72034d57a4835099aa94ec6f2cf/macports-ports (master):

graphviz-gui: fix builds for 10.11, with sdk 10.12
Fixes: #63597

[Christopher Nielsen <mascguy@…>]

In 134ef7c52137bc8d179fe866f2dfd02c72f30938/macports-ports (master):

graphviz-gui-devel: fix builds for 10.11, with sdk 10.12
See: #63597

[sambthompson (Sam Thompson)]

Thanks, @mascguy, can confirm successful build/install here.

Would still love to know why this issue with a new 10.13 symbol only affected one combo of OS and compiler of all the earlier ones.

[thetrial (alabay)]

Plusgood, doubleplusgood. Thanks a lot Mascguy. It ran through. I really can’t remember when I could run through a whole update/upgrade session with »and not«. Now I can.

[ryandesign (Ryan Carsten Schmidt)]

Replying to sambthompson:

Would still love to know why this issue with a new 10.13 symbol only affected one combo of OS and compiler of all the earlier ones.

Most of our buildbot machines use the last Xcode version that contains the SDK version that matches the OS version. That way, there is no confusion: symbols found at build time are available at runtime. On the 10.10 and 10.11 build machines for whatever reason I had decided at some point to update them to newer versions of Xcode that only have the next SDK. (The 10.10 machine's Xcode only has the 10.11 SDK; the 10.11 machine's Xcode only has the 10.12 SDK.) Probably I did this because some port would not build otherwise. But most ports for software that is not written specifically for macOS are not aware of how macOS SDKs work and they assume that symbols they find at build time are always available at runtime, which is not the case when you are building with a newer SDK. I don't know if that is exactly what's going on here, but it's one of the reasons this type of problem can occur.

Was this problem ever reported to the Graphviz developers? I did not see any issue filed there containing the string NSToolbarItemIdentifier. We don't want to carry patches around forever; the Graphviz repository is the correct place for a fix for this issue to be made, not in MacPorts. Possibly it doesn't matter anymore, because recently significant rewrites of Graphviz.app have been submitted upstream which, once accepted, may greatly increase the minimum required macOS version.

For now, though, graphviz-gui @9.0.0 worked fine for me on Mac OS X 10.7.5.

[sambthompson (Sam Thompson)]

Replying to ryandesign:

Most of our buildbot machines use the last Xcode version that contains the SDK version that matches the OS version. That way, there is no confusion: symbols found at build time are available at runtime. On the 10.10 and 10.11 build machines for whatever reason I had decided at some point to update them to newer versions of Xcode that only have the next SDK. (The 10.10 machine's Xcode only has the 10.11 SDK; the 10.11 machine's Xcode only has the 10.12 SDK.) Probably I did this because some port would not build otherwise. But most ports for software that is not written specifically for macOS are not aware of how macOS SDKs work and they assume that symbols they find at build time are always available at runtime, which is not the case when you are building with a newer SDK. I don't know if that is exactly what's going on here, but it's one of the reasons this type of problem can occur.

Thanks for this explanation. There certainly have been issues over the years with SDK versions mismatch around a number of ports (it's the most common cause of trac tickets I've raised, certainly), but these problems always seem to show up during build, not at runtime (as far as I know). I would have expected more issues on the buildbot machines with building where only the later SDK is available. Apple don't seem as concerned about maintaining backwards compatibility as say, Microsoft is.

Was this problem ever reported to the Graphviz developers? I did not see any issue filed there containing the string NSToolbarItemIdentifier. We don't want to carry patches around forever; the Graphviz repository is the correct place for a fix for this issue to be made, not in MacPorts.

Not reported by me. Per the questions raised above, I was not confident I understood the issue well enough to make an appropriate report upstream. Can see the preference is to get issues addressed upstream where possible rather than patch around them, though. I assumed the patch author would be best placed to identify upstream issues (i.e. to know whether the root cause was upstream or macports environment specific).

For now, though, graphviz-gui @9.0.0 worked fine for me on Mac OS X 10.7.5.

Just successfully built/installed same version here on 10.11.6.

[thetrial (alabay)]

Same here, V9.0.0 works with 10.12.

And wasn’t it so, that one can now add missing SDKs in MP? I did that, but, to be honest, forgot, if this construction is still in operation or if I left that again.