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 found → doxygen @1.9.4: fatal error: 'variant' file not found |
---|---|
Version: | → 2.7.2 |
comment:2 Changed 2 years ago by michaelld (Michael Dickens)
comment:3 Changed 2 years ago by michaelld (Michael Dickens)
Owner: | set to michaelld |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:4 follow-up: 8 Changed 2 years ago by michaelld (Michael Dickens)
Description: | modified (diff) |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
Summary: | doxygen @1.9.4: fatal error: 'variant' file not found → doxygen @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 earlier → doxygen @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 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 follow-up: 10 Changed 2 years ago by mascguy (Christopher Nielsen)
We also might want to create a devel port, to validate updates prior.
comment:10 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:
comment:11 Changed 2 years ago by mascguy (Christopher Nielsen)
Cc: | mascguy added |
---|
comment:12 Changed 2 years ago by Christopher Nielsen <mascguy@…>
comment:13 Changed 2 years ago by mascguy (Christopher Nielsen)
Port: | doxygen-devel added; doxygen removed |
---|---|
Priority: | High → Normal |
Summary: | doxygen @1.9.4: fails to build on 10.12 and earlier → doxygen-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@…>
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 earlier → doxygen-devel @1.9.4: build fails for 10.7 through 10.12: undefined vtable symbols |
---|
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:22 Changed 2 years ago by kencu (Ken)
comment:23 Changed 2 years ago by tehcog (tehcog)
Cc: | tehcog added |
---|
comment:24 Changed 2 years ago by kencu (Ken)
probably this commit did it
https://github.com/doxygen/doxygen/commit/d280c603c0141070e09a0e79ccb4c0855de85b92
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 follow-ups: 30 31 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 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 requiringdoxygen
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 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 requiringdoxygen
to allow using that port.
Done via commit:
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.
comment:34 Changed 2 years ago by kencu (Ken)
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 symbols → doxygen-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 23 months ago by larryv (Lawrence Velázquez)
Cc: | larryv added |
---|
comment:39 follow-up: 41 Changed 13 months ago by mascguy (Christopher Nielsen)
Cc: | michaelld added; mascguy removed |
---|---|
Owner: | changed from michaelld to mascguy |
Status: | reopened → assigned |
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@…>
comment:41 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:68529Per the other issue, we'll likely need to use
legacysupport
- withmacports-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: | assigned → closed |
well drat