Opened 2 years ago

Closed 13 months ago

#65314 closed defect (fixed)

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

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: mascguy (Christopher Nielsen)
Priority: Normal Milestone:
Component: ports Version: 2.7.2
Keywords: Cc: tehcog (tehcog), RobK88, larryv (Lawrence Velázquez), michaelld (Michael Dickens)
Port: doxygen-devel

Description (last modified by michaelld (Michael Dickens))

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.

Change History (42)

comment:1 Changed 2 years ago by ryandesign (Ryan Carsten Schmidt)

Summary: doxygen @1.9.4: fatal error: 'variant' file not found fatal error: 'variant' file not founddoxygen @1.9.4: fatal error: 'variant' file not found
Version: 2.7.2

comment:2 Changed 2 years ago by michaelld (Michael Dickens)

well drat

comment:3 Changed 2 years ago by michaelld (Michael Dickens)

Owner: set to michaelld
Resolution: fixed
Status: newclosed

In 827c0adbb15fcf5a8c1d02f9482b2929bd1426e9/macports-ports (master):

doxygen: now requires C++17

Closes: #65314

comment:4 Changed 2 years ago by michaelld (Michael Dickens)

Description: modified (diff)
Resolution: fixed
Status: closedreopened
Summary: doxygen @1.9.4: fatal error: 'variant' file not founddoxygen @1.9.4: fails to build on 10.13 and earlier

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

comment:5 Changed 2 years ago by michaelld (Michael Dickens)

Summary: doxygen @1.9.4: fails to build on 10.13 and earlierdoxygen @1.9.4: fails to build on 10.12 and earlier

comment:6 Changed 2 years ago by michaelld (Michael Dickens)

Description: modified (diff)

comment:7 Changed 2 years ago by michaelld (Michael Dickens)

Description: modified (diff)

comment:8 in reply to:  4 Changed 2 years ago by 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?

comment:9 Changed 2 years ago by mascguy (Christopher Nielsen)

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

comment:10 in reply to:  9 Changed 2 years ago by mascguy (Christopher Nielsen)

Replying to mascguy:

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

Done. See commits:

Last edited 2 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:11 Changed 2 years ago by mascguy (Christopher Nielsen)

Cc: mascguy added

comment:12 Changed 2 years ago by Christopher Nielsen <mascguy@…>

In 04be245452cfbf3ecf594ab0b234e24aea2ec03a/macports-ports (master):

doxygen: revert to 1.9.3
See: #65314

comment:13 Changed 2 years ago by mascguy (Christopher Nielsen)

Port: doxygen-devel added; doxygen removed
Priority: HighNormal
Summary: doxygen @1.9.4: fails to build on 10.12 and earlierdoxygen-devel @1.9.4: fails to build on 10.12 and earlier

comment:14 Changed 2 years ago by mascguy (Christopher Nielsen)

Cc: michaelld removed

comment:15 Changed 2 years ago by Christopher Nielsen <mascguy@…>

In d15ff498306a2f903b019a5a0eb93eda923af36b/macports-ports (master):

doxygen: revert to 1.9.3
See: #65314

comment:16 Changed 2 years ago by 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.

comment:17 Changed 2 years ago by 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...

comment:18 Changed 2 years ago by mascguy (Christopher Nielsen)

Summary: doxygen-devel @1.9.4: fails to build on 10.12 and earlierdoxygen-devel @1.9.4: build fails for 10.7 through 10.12: undefined vtable symbols

comment:19 Changed 2 years ago by michaelld (Michael Dickens)

Thanks for the work folks!

comment:20 Changed 2 years ago by 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!

comment:21 Changed 2 years ago by 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?

comment:23 Changed 2 years ago by tehcog (tehcog)

Cc: tehcog added

comment:25 Changed 2 years ago by 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.

comment:26 Changed 2 years ago by 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.

comment:27 Changed 2 years ago by 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 ... ?

comment:28 Changed 2 years ago by 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.

comment:29 Changed 2 years ago by 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.

comment:30 in reply to:  28 Changed 2 years ago by 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.)

comment:31 in reply to:  28 Changed 2 years ago by 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]

Last edited 2 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:32 Changed 2 years ago by michaelld (Michael Dickens)

Thanks @mascguy!

comment:33 Changed 2 years ago by 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.

Last edited 2 years ago by ryandesign (Ryan Carsten Schmidt) (previous) (diff)

comment:34 Changed 2 years ago by kencu (Ken)

In 770f2e2c230e8d5b086ec7faaf1565e771770507/macports-ports (master):

doxygen: bump epoch and add update note

closes: #66069
see: #65314

comment:35 Changed 2 years ago by kencu (Ken)

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

comment:36 Changed 2 years ago by 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++ :> ).

comment:37 Changed 2 years ago by RobK88

Cc: RobK88 added

comment:38 Changed 2 years ago by larryv (Lawrence Velázquez)

Cc: larryv added

comment:39 Changed 13 months ago by mascguy (Christopher Nielsen)

Cc: michaelld added; mascguy removed
Owner: changed from michaelld to mascguy
Status: reopenedassigned

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.

comment:40 Changed 13 months ago by Christopher Nielsen <mascguy@…>

In 050ecdb42455a9bca6b6381280a9c6fd1199a8c3/macports-ports (master):

doxygen-devel: update to 1.9.8

See: #65314

comment:41 in reply to:  39 Changed 13 months ago by 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.

comment:42 Changed 13 months ago by mascguy (Christopher Nielsen)

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.