doxygen-devel @1.9.5: build fails for 10.7 through 10.12: undefined vtable symbols

[ryandesign (Ryan Carsten Schmidt)]

Undefined symbols for architecture x86_64:
  "typeinfo for std::bad_variant_access", referenced from:
      std::__1::__throw_bad_variant_access() in libdoxymain.a(util.cpp.o)
      std::__1::__throw_bad_variant_access() in libdoxymain.a(xmlgen.cpp.o)
      std::__1::__throw_bad_variant_access() in libdoxymain.a(perlmodgen.cpp.o)
      std::__1::__throw_bad_variant_access() in libdoxymain.a(context.cpp.o)
      std::__1::__throw_bad_variant_access() in libdoxymain.a(mangen.cpp.o)
      std::__1::__throw_bad_variant_access() in libdoxymain.a(rtfgen.cpp.o)
      std::__1::__throw_bad_variant_access() in libdoxymain.a(htmlgen.cpp.o)
      ...
  "vtable for std::bad_variant_access", referenced from:
      std::__1::__throw_bad_variant_access() in libdoxymain.a(util.cpp.o)
      std::__1::__throw_bad_variant_access() in libdoxymain.a(xmlgen.cpp.o)
      std::__1::__throw_bad_variant_access() in libdoxymain.a(perlmodgen.cpp.o)
      std::__1::__throw_bad_variant_access() in libdoxymain.a(context.cpp.o)
      std::__1::__throw_bad_variant_access() in libdoxymain.a(mangen.cpp.o)
      std::__1::__throw_bad_variant_access() in libdoxymain.a(rtfgen.cpp.o)
      std::__1::__throw_bad_variant_access() in libdoxymain.a(htmlgen.cpp.o)
      ...
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.

[michaelld (Michael Dickens)]

well drat

[michaelld (Michael Dickens)]

In 827c0adbb15fcf5a8c1d02f9482b2929bd1426e9/macports-ports (master):

doxygen: now requires C++17

Closes: #65314

[michaelld (Michael Dickens)]

hmmm ... better, but still some issues ...

[mascguy (Christopher Nielsen)]

Replying to michaelld:

hmmm ... better, but still some issues ...

As a quick test, I tried upping the blacklist to ensure use of Clang 14, but that doesn't fix the issue either.

Given that this is a foundational build-related port, I'm wondering if we should revert for now?

[mascguy (Christopher Nielsen)]

We also might want to create a devel port, to validate updates prior.

[mascguy (Christopher Nielsen)]

Replying to mascguy:

We also might want to create a devel port, to validate updates prior.

Done. See commits:

• [486bc07cdf7a038bcbb7271d579ed140913e4bd0/macports-ports]
• [068e9cb12cb659d054f2150897d9dca12118cf65/macports-ports]

[Christopher Nielsen <mascguy@…>]

In 04be245452cfbf3ecf594ab0b234e24aea2ec03a/macports-ports (master):

doxygen: revert to 1.9.3
See: #65314

[Christopher Nielsen <mascguy@…>]

In d15ff498306a2f903b019a5a0eb93eda923af36b/macports-ports (master):

doxygen: revert to 1.9.3
See: #65314

[mascguy (Christopher Nielsen)]

Given the number of dependents, I'm reluctant to change all of those to use a path-style dep.

But with doxygen-devel, we can at least validate the build - and general functionality - prior to rollout.

[mascguy (Christopher Nielsen)]

As for the update to 1.9.4, it's interesting that the build succeeds for 10.6 (both x32 and x64), with Clang 11. Hmmm...

[michaelld (Michael Dickens)]

Thanks for the work folks!

[michaelld (Michael Dickens)]

The error is so strange, and it's even stranger that it builds with some Clang but not others ... really not sure what's going on there!

[kencu (Ken)]

I believe the system libc++.dylib in the failing systems is too old, and doesn’t contain the missing symbols.

The libc++ we install on 10.6 is newer than all those failing ones, so 10.6 passes.

What to do to fix it remains to be seen. Perhaps use the macports-libcxx port and static link libc++.a into the build?

[kencu (Ken)]

​https://github.com/llvm/llvm-project/blob/09c2b7c35af8c4bad39f03e9f60df8bd07323028/libcxx/test/std/utilities/variant/variant.bad_variant_access/bad_variant_access.pass.cpp#L11

[kencu (Ken)]

probably this commit did it

​https://github.com/doxygen/doxygen/commit/d280c603c0141070e09a0e79ccb4c0855de85b92

[michaelld (Michael Dickens)]

@kencu: Thanks for that sleuthing! Do you know where the "fix" is in libc++ (e.g., "the" commit)?

OK so we have "Throwing bad_variant_access is supported starting in macosx10.13" ... but ... if we instead use MP's libc++.a, which contains the fixes that are not in macOS/Apple's libc++.a, then this would "work around" the issue?

Is there some way we can use LegacySupport to declare the problematic symbols & then use that to work around the issue? That seems more tractable if we can do so.

[kencu (Ken)]

I'm not sure if we could find a way to dig out that one symbol from the libcxx code and have it make it's way into LegacySupport, but I think that path has dragons on it. I don't think that there is just one commit that brought this into libcxx; it was a process.

And upstream libcxx has not been overly keen on keeping around luggage to allow older MacOS systems to work around this. There were other libs, etc, in some earlier versions of clang for libfilesystem, for example, and once these were rolled into libcxx, these workarounds for MacOS have been removed.

macports-libcxx would just be a build dep. You would link in the libc++.a from there statically into doxygen. This would "probably" work. You might have to force libc++.dylib to NOT link in by using "-nodefaultlibs" I believe is the argument.

It's somewhat of a messy PITA, for sure. And it is possible that some ODR violations would subsequently be found that make this troublesome, but you never know about those until you're into it. Usually there are none.

Otherwise, I guess we peg doxygen forever at this last version.

[michaelld (Michael Dickens)]

Ug ... none of those sound like great options. How do we do this on OSX 10.6 (and presumedly 10.4 and 10.5) so that it (those) get the newer libc++? Could we not somehow replicate that for 10.[7 - 12]? Maybe you've already described this in one of your prior messages & I just didn't get it ... ?

[michaelld (Michael Dickens)]

Thinking this a bit further: I think we should move back to a single Portfile: allow the current release for OSX 10.[4 - 6] and 10.[13 - 15], 11, & 12 (& the forthcoming 13); peg OSX 10.[7 - 12] at current. The doxygen-devel port is a great idea but not for general end-users because it requires a change to the Portfile requiring doxygen to allow using that port. Moving to the peg+new allows a single Portfile & then we can much more easily test updates.

[kencu (Ken)]

the libc++.a thing is fairly easy, and worth trying I think for someone motivated. Perhaps peg doxygen for now until someone wants to take that on?

On 10.6 we install a libcxx that is newer than the ones on 10.7 to 10.12. So it strangely turns out to be able to run more software than 10.7 can, as time goes by :>

On 10.4 and 10.5 you use libstdc++ from gcc which is very new.

I tried installing the newer libc++ on 10.7, and it does work for a while, but then some of the old Apple apps (iCal for example) were crashing.

[mascguy (Christopher Nielsen)]

Replying to michaelld:

The doxygen-devel port is a great idea but not for general end-users because it requires a change to the Portfile requiring doxygen to allow using that port.

That's easy enough to fix, and I'll take care of it. (Sometime over the next day or so.)

[mascguy (Christopher Nielsen)]

Replying to michaelld:

The doxygen-devel port is a great idea but not for general end-users because it requires a change to the Portfile requiring doxygen to allow using that port.

Done via commit:

[a072126e47f6771bb722c1a4c396465b0ab3ebe5/macports-ports]

[michaelld (Michael Dickens)]

Thanks @mascguy!

[michaelld (Michael Dickens)]

As noted in the Volk 2.5.1 issue (#65377), and applicable here: What to do here? I'd love a more universal solution for the libc++ issues. We have this Volk one (std::filesystem) as well as the recent Doxygen one. We can try static linking of MP-libc++.a, but that will currently be a one-off solution for each port. It'd be great if we could somehow just move MP to use the MP-libc++.dylib ... @kencu is probably the most knowledgable about this! Do we have a MP ticket up for this discussion already? If so then we can tag it here & close this issue.

[kencu (Ken)]

In 770f2e2c230e8d5b086ec7faaf1565e771770507/macports-ports (master):

doxygen: bump epoch and add update note

closes: #66069
see: #65314

[kencu (Ken)]

If a few folks would like to try adding this to doxygen-devel:

legacysupport.newest_darwin_requires_legacy 17
legacysupport.use_mp_libcxx yes

and then running the test suites on the affected systems, that would go a long way to seeing if this approach is viable.

If that doesn't work out, there could be a doxgyen-legacy port pegged at 1.9.3 and everything < darwin 17 could use that (although in the odd way of things, 10.4, 10.5, and 10.6 could likely build the current version, as well as 10.7 and 10.8 that are not using libc++ :> ).

[mascguy (Christopher Nielsen)]

This is now an issue for doxygen as well, with the latest update to 1.9.8: issue:68529

Per the other issue, we'll likely need to use legacysupport - with macports-libcxx - to resolve this.

[Christopher Nielsen <mascguy@…>]

In 050ecdb42455a9bca6b6381280a9c6fd1199a8c3/macports-ports (master):

doxygen-devel: update to 1.9.8

See: #65314

[mascguy (Christopher Nielsen)]

Replying to mascguy:

This is now an issue for doxygen as well, with the latest update to 1.9.8: issue:68529

Per the other issue, we'll likely need to use legacysupport - with macports-libcxx - to resolve this.

Ah, it looks like @kencu already took care of this, via commit:

doxygen-devel: use macports-libcxx when needed

So we simply need to reconcile doxygen with doxygen-devel, and we'll be set.

Well, almost: Builds fail for 10.6, and we still need to address that. Ditto for 10.5, though the latter is related to pthread and friends.