#58347 closed defect (fixed)
Error: Failed to build dvisvgm: command execution failed
Reported by: | dbl001 (dbl) | Owned by: | michaelld (Michael Dickens) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.5.4 |
Keywords: | Cc: | Blokkendoos (Johan) | |
Port: | dvisvgm |
Description
:info:build AttributeExtractor.cpp:116:24: error: constexpr variable 'names' must be initialized by a constant expression
I'm getting the following error building: dvisvgm
$ sudo port upgrade outdated Password: ---> Computing dependencies for dvisvgm ---> Building dvisvgm Error: Failed to build dvisvgm: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_dvisvgm/dvisvgm/main.log for details. Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Attachments (2)
Change History (15)
Changed 6 years ago by dbl001 (dbl)
comment:1 Changed 6 years ago by mf2k (Frank Schima)
Keywords: | dvisvgm removed |
---|
comment:2 Changed 6 years ago by michaelld (Michael Dickens)
Keywords: | dvisvgm added |
---|
comment:3 follow-up: 7 Changed 6 years ago by Ionic (Mihai Moldovan)
Forcing macports-clang-6.0
worked for me.
Note that make_array
is an experimental feature - not part of either C++11, 14, or even 17. It's scheduled for maybe-inclusion in C++20, but no guarantees.
It was implemented in clang in Oct 2017, past the release of clang-5.0 (~Sep 2017). The first version to have proper support for it is thus 6.0.
Since the C++11 1.1 PG already forces mp-clang-5.0 via compiler.whitelist (which is really a compiler.force operation...), using compiler.whitelist macports-clang-6.0
in dvisvgm
should be enough to get this fixed across the board.
comment:4 Changed 6 years ago by Ionic (Mihai Moldovan)
Err, actually, that only holds for systems using libc++ and are not too old.
We'd really have to reimplement the cxx11-1.1 PG in dvisvgm
, because we naturally want to keep ppc machines on gcc-6 of course.
So rather something like
if {${configure.cxx_stdlib} eq "libstdc++"} { if {(${os.platform} ne "darwin" || ${os.major} >= 10) && ${build_arch} ne "ppc" && ${build_arch} ne "ppc64"} { compiler.whitelist macports-clang-6.0 } } else { compiler.fallback-append macports-clang-6.0 compiler.blacklist-append {clang < 600} macports-clang-3.* macports-clang-4.0 macports-clang-5.0 }
comment:5 Changed 6 years ago by mf2k (Frank Schima)
Keywords: | dvisvgm removed |
---|
comment:6 Changed 6 years ago by Blokkendoos (Johan)
Cc: | Blokkendoos added |
---|
comment:7 Changed 6 years ago by mgieseki (Martin Gieseking)
Replying to Ionic:
Note that
make_array
is an experimental feature - not part of either C++11, 14, or even 17. It's scheduled for maybe-inclusion in C++20, but no guarantees.
I stumbled over this ticket about the build issue. Just for clarification: dvisvgm does not use std::make_array
but provides its own implementation util::make_array
defined in utils.hpp
. The sources build fine for me on Linux even with GCC 4.8.
comment:8 Changed 6 years ago by Ionic (Mihai Moldovan)
Okay, so my analysis was wrong, but it must still be using a feature (no idea which one) only available in clang-6.0+ and not older versions.
comment:9 Changed 6 years ago by Ionic (Mihai Moldovan)
Turns out michaelld was probably right - std::forward
is constexpr since C++14, which is needed here. Not sure why that code would compile in C++11 mode even with newer clang versions (or, for that matter, g++), since it should be non-constexpr in C++11 mode.
Edit: probably because marking something constexpr has no negative side-effects, so it doesn't have to done conditionally. That's just a guess, though.
Changed 6 years ago by mgieseki (Martin Gieseking)
Attachment: | make_array.patch added |
---|
comment:10 Changed 6 years ago by mgieseki (Martin Gieseking)
std::forward
is indeed a problem. I'll drop the make_array
stuff in the next release of dvisvgm. If you like, you can already apply attachment:make_array.patch to fix the build issue.
comment:12 Changed 6 years ago by michaelld (Michael Dickens)
Owner: | set to michaelld |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:13 Changed 6 years ago by michaelld (Michael Dickens)
Done! Thank you @mgieseki for the quick fixing of this issue!
Hmm ... looks like although it's checking for c++11, it really requires c++14. Let me see about patching it & restricting compilers to one that's c++14 compliant ...