Opened 14 months ago
Closed 8 months ago
#67076 closed defect (fixed)
qpdf 11.3.0_0 fails to build on mavericks
| Reported by: | tehcog (tehcog) | Owned by: | |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.8.1 |
| Keywords: | Cc: | Schamschula (Marius Schamschula) | |
| Port: | qpdf |
Description
please see attached main.log
Attachments (1)
Change History (9)
Changed 14 months ago by tehcog (tehcog)
| Attachment: | qpdf_main.log added |
|---|
comment:1 follow-up: 2 Changed 14 months ago by Schamschula (Marius Schamschula)
It looks like your compiler is too old: See https://github.com/TRIQS/triqs/issues/535 and https://bugs.llvm.org/show_bug.cgi?id=33222
It looks like we'll have to black list older compilers.
comment:2 Changed 14 months ago by tehcog (tehcog)
Replying to Schamschula:
It looks like your compiler is too old: See https://github.com/TRIQS/triqs/issues/535 and https://bugs.llvm.org/show_bug.cgi?id=33222
So my instance is not using 'clang-15 @15.0.7_1' even though it is installed?
comment:3 Changed 14 months ago by ryandesign (Ryan Carsten Schmidt)
The log shows clang 15 is being used.
comment:4 Changed 14 months ago by kencu (Ken)
It's actually not the compiler itself -- the system libc++.dylib on 10.9 doesn't have the needed symbols in it.
1013 :info:build Undefined symbols for architecture x86_64: 1014 :info:build "typeinfo for std::bad_variant_access", referenced from: 1015 :info:build __ZNSt3__126__throw_bad_variant_accessB6v15007Ev in QPDFValue.cc.o 1016 :info:build __ZNSt3__126__throw_bad_variant_accessB6v15007Ev in QPDF_json.cc.o
using macports-libstdc++ (via legacysupport) can sometimes fix this. Alternatively there are a few other ways to add the missing symbols that macports could consider.
comment:6 follow-up: 7 Changed 13 months ago by erikbs
Somehow I missed this ticket when I opened my PR and therefore did not reference it, but the issue disappeared when I added legacy-support to the Portfile: https://github.com/macports/macports-ports/pull/18179
The port also seems to build fine when linking against libstdc++ instead of libc++, but since the legacy-support approach was much easier, I went with that.
comment:7 Changed 8 months ago by tehcog (tehcog)
Replying to erikbs:
The port also seems to build fine when linking against libstdc++ instead of libc++, but since the legacy-support approach was much easier, I went with that.
Works for me now... Thanks
comment:8 Changed 8 months ago by Schamschula (Marius Schamschula)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
main.log